The Unanticipated Consequences of Containerization

Print Friendly, PDF & Email

In this special guest feature, Marc MacLeod, Stoplight Founder & CEO, suggests that while containerization and microservices are an effective solution to modern problems of scalability, they also introduce a new set of problems. Marc began programming at an early age and started his first profitable company at age 16. Since then, he has worked in leadership roles at several startups, and as an API consultant and expert. He is also a Mass Challenge $50k winner and a Techstars graduate.

Imagine that you’re building a development with 500 houses. You don’t want to end up with a bungalow, a colonial and a loft all spackled together. Yet this is the inevitable result if none of the builders are talking to each other and there’s no easily accessible master plan.

As tech companies increasingly break down their APIs into microservices, they’re running into similar problems. Thanks in large part to containerization, companies’ development teams can work on hundreds or even thousands of microservices at any given time. Google, for example, runs everything on containers, deploying an incredible two billion containers each week.

While containerization and microservices are an effective solution to modern problems of scalability, they also introduce a new set of problems. A lack of cohesive design strategy can  lead to a hodgepodge of ill-fitting APIs at companies, with duplicated services, inconsistent design patterns and all the consequences that cascade from there.

While microservices are and will remain an essential part of the modern development lifecycle, it’s time to update the company culture and systems architecture to match. If companies don’t adjust their development approach to meet the unique challenges of managing thousands of small decoupled APIs, containerization and microservices will never reach their full potential.  

Companies aren’t ready to give up on containerization’s benefits

In the early days of applications, most companies had one or two monolithic application programming interfaces (APIs) developed by a cohesive tech team. That team — whether it was a few developers or a dozen — would talk to each other, use a wiki for visibility, and make sure that nothing fell through the cracks. This also worked in a time when far fewer apps operated in the world, and nobody dreamed that data would reach the “new oil” status celebrated today. 

In our world of excess data and increased automation, It’s easy to see why companies are so enamored with containerization, and why there’s no way to turn back the clock. Under pressure to scale their technology and running up against limited capacity, containerization is an obvious choice. By sharing parts of a single operating system among multiple isolated applications, it takes just seconds to start a container, while it would take minutes to start up the entire operating system. 

This is beneficial for massive distributed applications with lots of discrete parts that need to be summoned, run and then killed in short order. It’s also much more efficient from a CPU utilization perspective, which matters if you’re an IT-focused organization. If there is lots of traffic to one specific area, each API can scale up independently and can also deploy individually.  

Simply put, containerization lets companies employ a combination of speed and decentralization to empower scalability. Today, it is an essential part of any large company’s approach to APIs. 

The unintended consequences of containerization

Thanks to containerization, small teams are commonly managing, deploying and distributing code for individual taks without centralized oversight. That autonomy may be sustainable in a small company, but in a big company with dozens of teams working autonomously on hundreds or thousands of microservices, it’s leading to chaos.

Inconsistency is perhaps the biggest resulting problem. For example, each team may do pagination in a different way, and all of a sudden you have to account for all of those slight differences. One API might work with a “user,” another might call it a “customer,” a third will call it a client. When teams don’t talk to each other, even small errors and inconsistencies like these can lead to a cascading chain of breakage as incompatibilities manifest and programs become difficult to integrate.

Other common problems include duplication of services, a lack of mobile compatibility and a general mismatch between how the API was built and actual needs of the consumer. Fixing APIs after implementation is possible, but it costs between 50 and 100 times more than solving during the planning stages.

How to roll back the consequences using API architects

It’s time for tech companies to reclaim a strategic, intentional approach to APIs. APIs should be treated as a first-class citizen, with well-thought-out processes and tooling to help manage them at scale. The easiest way to do so is to assign responsibility and make it someone’s job: every company should consider designating API architect roles, filled by highly experienced developers. 

API architects should manage the company’s API design at scale. In addition to overarching design strategy, an API architect should also focus on improving workflow collaboration, thinking intentionally about how to increase visibility of what other teams are doing in order to minimize inconsistencies and encourage re-use of common patterns. To be successful, an API architect should span multiple teams. 

Other best practices include creating a centralized place where everyone can search comprehensive documentation on what’s been done previously. There should also be some sort of a governance or review process, so that developers can’t just change designs of their own accord without considering how it would affect downstream consumers.

These actions will help to bring about the most critical step of all: culture change. Tech companies must get back to the model where developers feel like one API team with one mission, no matter how many independent distributed teams they’re broken into. Then—and only then—will tech companies be able to reap the benefits of containerization and microservices at scale. 

Sign up for the free insideBIGDATA newsletter.

Speak Your Mind

*

Comments

  1. In the paragraph starting “Other best practices include creating a centralized place where everyone can search comprehensive documentation on what’s been done previously…” you touched a bit on what I think API catalogs and service meshes help solve. When they are properly integrated with CICD pipelines it can be very helpful to teams in understanding and communicating the big picture. It also helps developers avoid the pitfall of developing in a silo and also understanding more of the potential business impact they have. You summed it up at the end with a need for culture change and I think there’s a bit devops has on culture change and collaboration.

  2. Anit Shrestha Manandhar says

    Good read indeed. Thanks.
    I would like to add is – DOCUMENTATION, should be the first class citizen in the engineering culture overall. The pain point in having ONE set of thing to make a base depends on how clear the GUIDELINES are mentioned and how easy it is to understand WHAT DOES WHAT, the relationship at scale.
    Thanks again.