The flaws in the you build it, you own it strategy

In today’s rapidly developing landscape identifying the best strategies for seamless software delivery and optimal tool integration can be challenging.

Rob Zuber, CTO at CircleCI, shares his insights on building and leading a successful growth company. He shares his experience on harnessing the strategic potential of DevOps and platform teams, the shift in the You Build It You Own It method, and revolutionizing traditional practices to enhance the developer experience. 

The evolution of software engineering

“The fascinating thing about software engineering as a discipline is that software engineers are very uncomfortable with things staying the same. The thing we love to do the most is change the way we do everything,” says Zuber. 

That being said, it’s no surprise that software engineering, its processes and tools have grown and changed rapidly over time. 

Back in 2011, when CircleCI first started, everything was web-first. Software engineers were using Rails apps on Heroku.

“When you scaffold a Rails app, the first thing it does is spit out tests, which was fundamentally changing the way software developers thought about building good code,” says Zuber. 

Test-driven development started taking off and proving that testing led to delivering software and to finding product-market fit faster. 

“Everyone was talking about this shift, and Circle CI landed in the middle of that. Everyone was saying absolutely, I need to do CI, and I absolutely don't want to do it myself,” Zuber says. 

But by 2014, only three years later, everything shifted again from being primarily web-based to mobile-first or sometimes even mobile-only. This shift required engineers to be more adaptable to new tools and systems.

“Suddenly, Rails developers were like, ‘Wait a second, what we should do now is go build mobile apps,’ and then they showed up in the iOS community and started influencing how we build software,” Zuber says. 

From there, things moved toward containerization and developing microservices. “There's real value in breaking apart your system into components and allowing teams to work independently,” Zuber says. 

The one constant in all this change, though, is the overall goal of software engineering — to ship software quickly into the hands of customers and get their feedback for continuous improvement.

“At the end of the day, it doesn't matter whether you're trying to build a Rails monolith or a distributed set of go and rust microservices if you can't keep control of your environment,” says Zuber. 

What truly matters is trying to get a great product out to your customers faster.

Increased complexities and challenges in the shift toward microservices

One notable result of the evolution of software engineering is the increased complexity of not only the software but also the tools and processes used to create it. 

“We've taken things that we understood, like the monolith, and decided it’s too complex. We decided to break it down into a bunch of microservices and sort of bury logic in the network where we can't see it, so part of how our product and our capabilities have evolved has been around surfacing interconnects with dependencies and things like that,” says Zuber. 

With increased complexity comes more dependencies, more uncoupling and challenges.

Three key challenges when deploying and testing microservices

1. Misunderstanding the “distributed monolith”

“Everyone loves to use the expression ‘distributed monolith,’ but no one knows what they mean when they say it,” Zuber says. “What we end up seeing is people trying to test seven different microservices simultaneously because that's the only way they can actually achieve something, which should be a sign that your decomposition is actually not serving you.”

The goal when considering decomposed systems is for each component to be individually testable to a very high degree. 

2. Missing opportunities for global optimization

“In a lot of engineering organizations, the selling point of microservices is being completely independent and doing whatever you want. But it misses opportunities for global optimization,” Zuber says. 

For example, it seems beneficial for teams to have and to use preferred toolkits, languages and/or frameworks, but think about when someone wants to expand their career and move to another team, things need to be consolidated or an incident requires everyone to look at what’s happening across the whole system. 

If every part of the system works differently, the allure at the individual level wears off, and the cracks start to show the missed opportunities for system-wide optimization.

3. Missing the mark with platform teams and the You Build It You Own It strategy

“There's been this rise of the platform team, at least in nomenclature, and it's been a lot of ‘we’ll manage Kubernetes for you, and when you need to deploy your thing, here's how you write a Helm chart.’ rather than ‘you don't even need to know this thing is in Kubernetes, so you write your software and we’ll take care of the rest,” says Zuber.

Leverage is lost when an individual developer needs to understand not only the tools and systems they’re using but also the entirety of what the platform team is using. 

The flaw in the You Build It, You Own It system ends up being that the platform team hasn’t really given the developer a lift, but instead, they give the developer more to manage.

Optimizing developer tools for use by developers

Typically, when working in a model within a monolith, all the basics like how you connect to the database and where the database is are taken care of. This allows the focus to be on building business logic. 

Then, as you break into microservices with product teams thinking about the end product to be delivered to customers, you want those product teams to be thinking of the same things.

“If I’m reimplementing how to connect to the database, questioning how I put things onto a queue, or wondering what the messaging service to pass information around is, then I’m becoming less effective as an engineer because I’m asking every engineer in my organization to understand things that used to be understood by just a few people,” Zuber says.

Expecting this higher level of understanding can be a hindrance and is essentially the opposite of the goal of a platform team, but things are starting to shift toward the use of true platform teams and product thinking. There are many primitives already built and ready for engineers to start using.

The key when using these primitives is for platform teams to understand what the product engineers using their tools are trying to achieve and then provide a platform that allows them to optimize with very few knobs or that does the optimization on the engineer’s behalf. This requires communication and allows for encapsulation. 

“I just want the minimum amount of understanding because ultimately it’s about being able to change, right? Encapsulation allows you to change all your stuff without others having to know about it,” Zuber says. 

Think of it as the difference between having to put tickets on backlogs of every team in the organization and notify them they’ll be doing things differently and being able to designate a maintenance window for changes not everyone needs to know about and rely on the engineer's background context to manage issues that may occur. 

It’s easy to think the developers using a platform will have the background knowledge to bridge gaps and fix issues in software, but that overlooks their need for a simple, ready-to-use tool. 

‍

Interested in learning more? Listen on Apple, Spotify, or your favorite podcast player.

‍