Microservices are small API-driven applications that are each responsible for doing one thing well in the pursuit of a common goal.
This definition sums up most popular general definitions of microservices. And, done right, microservices really can do all of the wonderful things that they are meant to do. Architecturally and procedurally, microservices hold a number of meaningful advantages over more-monolithic approaches toward application development. There are legitimate reasons we all look at the success of companies like Amazon and Netflix, and find ourselves thinking, "Microservices! That must be it!"
However, I'm not fond of this loose definition because it completely omits one of the key motivations behind building microservices: Allowing teams to deliver features to production faster and with less friction. Microservices achieve maximal utility only when the right software culture is in place. An organization looking at microservices should also embrace, and deliver on, some big cultural shifts in the way it values developer and operator productivity.
At a high level, there are three harsh truths organizations considering, or implementing, microservices will need to consider. And, unsurprisingly, each truth focuses on people and culture more than tooling or architecture.
- You can't do microservices well unless you're a company that is motivated to attract and retain great talent in the name of continued growth. Your goal doesn’t have to be growing like Facebook circa 2009, but you do need a real determination to continually grow the business and an appreciation of the role that good software talent can play in that.
- You can't do microservices well in a culture of decline with employees who are stuck in survival mode. A survivalist culture is a type of environment that stifles the flexibility and risk-taking that microservices are supposed to bring, and it will actively drive out your most talented employees. Talented software builders are people who are eager to experiment and discover new best practices, rather than to learn what not to do.
- You (probably) can't do microservices well if you’re “promoting” all your most talented developers into management roles. The microservices architecture was designed and made popular by hyper-growth companies that prioritize engineering, which means microservices require talented and skilled people working on them. Some of these people will thrive—along with your business—if you give them opportunities for career advancement in a technical track rather than just a management track.
Companies that embrace and address problems related to cultural decline and a slow pace of growth will fare much better when attempting to make microservices successful. Here’s why.
In high-growth companies, people are the process
The mythos of microservices has an origin story that starts with Amazon and Netflix. These are two of the world's most valuable—and, at one time, fastest-growing—companies, and their leadership on embracing new architectures and infrastructure models helped teach the world what it means to build cloud-native applications. But when we think now about the motivations behind why Amazon and Netflix bet big on microservices, we start to see a more detailed picture of why they succeeded with the shift. A large, but underappreciated, factor is that skilled developers thrive in environments with loose coupling and personal autonomy.
A centralized architecture will inevitably issue something I call cultural speeding tickets—the results of defects that occur when trying to deliver features on-time in a monolithic software project. Talented developers will try to avoid them by innovating and offering up ideas to management that will help preserve their freedom, autonomy, and velocity. Microservices at Amazon and Netflix weren’t part of the business plan. They were the result of software engineers and operators finding a way to reduce wasted effort, and to build and operate their applications in ways that facilitate a faster and safer pace of development—without the speeding tickets.
For many people, an all-too-relatable counterexample to a high-growth software company is Initech, the fictional employer in the cult-classic movie Office Space. The central characters are software developers who are stifled by a lack of freedom and autonomy. They’re plagued by anxiety and carelessness because they’re in survival mode—trying to stay employed (or at least entertained) at a company that very much values process over people. Management consultants flood in and are asked to cut costs, sending a panic through the company’s workforce who feel forced to justify their existence. In the real world, as in the movie, that type of situation typically doesn’t end well for employee or employer.
Too often, today’s software development landscape is likewise split into two bifurcated factions: the high-growth tech companies and everyone else. The widespread adoption of microservices has the potential to help bridge that gap, but only if the companies adopting microservices are making the change for the right reasons. And the best way to improve software architecture is to first to address a company’s culture—especially if it’s the kind that results in the stagnation of progress and the defense of legacy processes that have triggered a survival mode among employees.
Everyone wants freedom, efficiency, and control
Microservices have always wanted to happen, though, in part because legacy software practices can contribute to a stagnant culture. Developers have always wanted more freedom to automate infrastructure without needing to talk to operations, while operations have always wanted more freedom to automate the management of infrastructure—mostly to prevent outages caused by developers making constant changes. These desires stem from the difficulties that are inherent in managing shared infrastructure for a monolithic application.
Every change to this kind of architectures is a risk to system stability. Every guardrail is an impediment to change. Toe-stepping is a norm in this culture of software, where carelessness by one person causes someone else to come in on the weekend to clean up messes. So the desire for something like microservices was always there. The advent of cheaper, more automated infrastructure, thanks to cloud-native and open source tooling, has made it easier to deploy microservices (if you want some war stories on how that worked pre-cloud, I have plenty to share), but the difficulty and expense of changing culture remains the primary roadblock.
However, just because you can start firing up microservices on a Kubernetes cluster doesn’t mean should you rush into doing that. What many companies fail to realize is that the time and effort spent deploying—and possibly failing at—microservices could be better spent on first scrutinizing the pathways to production, and potentially preparing to automate deployment pipelines into a repeatable practice. If it takes weeks just to get your first line of code deployed to production, then you should be looking at upgrading your tooling to use practices such as continuous delivery.
You want to make life easier and more efficient for your teams before introducing a new type of complexity into an architecture.
Source: https://www.slideshare.net/adriancockcroft/goto-berlin
Try imagining the move from a million-line monolith to 500 microservices. It’s kind of like if LAX only had one power outlet per concourse, with tens of thousands of passengers roaming the concourse hoping to find it and use it. LAX would quickly need to figure out how to go from 1 outlet to at least 10,000 outlets. One option would be to buy a lot of extension cords and multiply the number of sockets. It would end up with wires wrapping the hallways like snakes on a plane, all rooted from one single socket. No airport would ever do this, but we do it in software all the time.
Or it could do the right thing: knock down some walls and rewire the system to support more wall sockets. Doing the right thing takes courage, and it takes a mindset from the very top that says, “It’s OK to knock down some of these walls if it means fewer people tripping over each other or fighting for control of a single codebase.”
New architectures need new cultures
The transformation of your software architecture, whether via microservices, functions or whatever comes next, requires the type of change that only results from an organic process rooted in supporting a healthy culture. In this type of environment, microservices can actually be a force multiplier. Now, both developers and operators can get their way—which means a happier, more productive team and, ultimately, a more productive digital business.
So how do you get there? Here are just a few things you can start doing to change your software culture:
- Encourage employees to solve problems by incentivizing new solutions and minimizing the risk of making mistakes.
- Bolster creativity using hackathons or some other type of free-thinking exercise.
- Improve collaboration by experimenting with practices such as pair programming.
- Establish a sense of community and engagement by open sourcing some of your internal tools and hosting meetups at your office.
- Show your employees you value their talent by hosting tech talks where they can share side projects or other tech interests.
- Experiment with new technologies and software practices by launching greenfield projects.
- Find new ideas and points of view by hiring a more diverse team.
If you're doing all of these things regularly, then you're acting like a business that’s ready for microservices—because you’re acting like a company that wants to attract and retain the talent it needs to keep growing.
It’s important to remember that microservices are not a destination. Microservices are just one part of a larger journey for a digital business that seeks to survive in a world that is dominated by software. And upgrading your culture matters just as much as upgrading your tooling
