Any company considering a shift to a microservices architecture must understand that this isn’t just about changing the way applications are built. It entails significant organizational challenges as well.
Is your company considering a move to microservices? If so, they need to understand that this isn’t just a shift to a different way of building applications. It entails some pretty significant organizational challenges as well. In the past, or often in the early days of a company’s history, software was constructed as single monolithic application based on a tightly-coupled single code base, often lacking modularity. When you wanted to add a feature, you simply added more code on top of the existing application.
This approach made large applications very difficult to scale. It frequently resulted in a sprawling Winchester Mystery HouseOpens a new window of codebase that was only as reliable as the most fragile piece of code in the system. Instead of a series of small structures with distinct purposes, it became one big Frankenstein building.
If this kind of IT situation sounds familiar to you, you’re in very good company. Right now there are several well-known unicorn companies chained to huge, unwieldy codebases with very little operational resiliency.
But then along came the concept of small services communicating over https — the little, canny mammals to the monolithic database dinosaurs: microservices.
Microservices break down large, unwieldy applications into their core functions – a set of discrete, independent processes. A microservice itself is basically just a self-contained process that provides a unique business capability – a search, purchase order, revenue service, etc. That breakdown into microservices also means that there is no longer a monolithic database and systems can no-longer rely on database transactions. Instead, application logic needs to add state transitions (ex: “pending†to “completedâ€) and rollbacks, which add complexity for application developers. However, the underlying benefit is scale.
Creating a microservice-based architecture is sort of like making a “machine for building machines.†Microservices communicate with each other through a well-defined interface, usually involving application programming interfaces, or APIs. The key point is that all these plug-and-play modules can communicate with one another seamlessly, and together build an infrastructure for managing the microservices (you need services that help support creating more services, too).
The communication is almost always stateless (a nimbler process in which the service doesn’t need to track “state†across calls, as each one operates independently and is not dependent on the next callâ€), and the individual microservices themselves are federated, meaning they are responsible for their own data model and data stores, giving greater flexibility in the technology you choose. This is how complexity gets reduced and scaling can happen.
Indeed, as long as these microservices can communicate with one another effectively, they don’t even have to be built with the same code. The concept of a complete lack of central processing and a variety of conflicting code might inspire heart attacks in certain kinds of database administrators, but microservices are still clearly the way forward.
The loose coupling of services means each one can be modified individually, without sinking the entire ship. And instead of working weeks or even months on a big release, development teams can iterate constantly.
But as many companies transitioning from monoliths to microservices are discovering, the biggest benefit of this data model is its effect on how you operate as a company. In other words, the code starts coding you.
Perhaps you’ve heard of Conway’s Law — the clever adage which states that software teams tend to design software that resembles their own organizational structures (top-down, distributed, etc). On the Internet you’ll find plenty of satirical org charts demonstrating this principle.
When you transition to microservices, the opposite effect occurs – in a way, the new code repositories behind each service start restructuring the organization.
It re-engineers all your core functions: engineering, operations, quality assurance, program management, product management, and even customer support.. By definition, you start moving away from heavy, top-down structures and into nimbler, distributed teams (or Jeff Bezos’ famous “two pizza†model).
Some of these changes are welcome to software developers, and some are not. As teams become more autonomous and cross-functional, managers can lose responsibility. Depending upon the personality type in question, this can get problematic. Deployment functions get taken away from tech ops and placed directly on engineering teams – again, more disruption.
Automation is essential, which means people can lose their pet projects. Automated tools will need to replace traditional processes and handoffs. While sometimes this is a welcome change, other times it can be seen as disempowering.
Microservices also force you to rethink your hiring — the kinds of developers you hire, and the places where you put them. If your organization is still functioning in separate engineering, tech operations, product, and quality assurance silos, then microservices will break them down, whether you like it or not.
The ultimate objective is to foster an environment where teams can work cross-functionally and focus on core product features and seamless product delivery over the addition of momentarily attractive next-gen “extrasâ€s to an existing application. That’s the mentality that microservices brings to your company.
Here are five suggestions for successfully navigating the shift to microservices.
1. Embrace cross-functional complexity
Eliminating silos and building teams that can effectively work cross-functionally is paramount to the long-term maintenance of a successful microservices architecture, and must be the first step towards an enterprise-wide shift.Resist the urge to take the simple route by building and migrating a new monolith. Embrace the intricacies of microservices and reinvent your offering according to overarching business needs, not just based on what’s feasible technologically.
2. Let metrics drive
Once a cross-functional team is built out, the next step is to incrementally break apart the existing infrastructure, reinventing one functional module at a time while keeping the appropriate metrics at the center of each microservices team. Simply duplicating current functionality into new services isn’t sufficient; new success metrics must be defined for each new service.
3. Manual Projects Out. Automation In
Dependence on tickets to confront and solve for bugs is an old-school process ripe for change. Tech teams must be encouraged to solve problems proactively – automation being a key element to streamline processes. For example, our infrastructure engineering team adjusted processes to move away from addressing standalone problems to building tools enabling microservice teams to approach and address issues as they emerge.
4. Learn from early mistakes
Periodic working sessions to improve and iterate on APIs being created – (in addition to addressing functional changes required) are critical to a successful microservices architecture transformation. Inspire your teams to come to the table with new innovations and ideas, but also stress the importance of learning from their mistakes to foster an environment of continuous learning.
5. Start small, then grow
During the course of a microservices architecture transformation, it’s imperative that the existing monolith be allowed to function as usual, eliminating any cause for concern. Take a gradual approach when building out your microservices team – starting small and growing as new complexities arise. However, abstain from restructuring engineering titles for the monolithic application team versus the microservices team as this discourages new ways of working. This also establishes effective collaboration and aligns the entire team to the overarching initiative.