Microservices: Trading Code Complexity for Organizational Complexity
Written by the Skiplist Team
In this article we take a look at microservices, defining what they are, why they are important, and whether or not they are right for your business.
What Are Microservices?
Microservices, or Microservice Architecture, is a collection of independent services and autonomous components. Microservices enable an application to be a collection of services are loosely coupled, highly maintained, owned by small teams, and independently deployed. Companies such as Google and Facebook are prime examples of what microservice architecture can produce.
Why Are Microservices Important?
Microservices are vital and advantageous for your business because they allow for small autonomous teams to deliver the best possible software.
This will ultimately enable you to structure your organization to rapidly deliver value-driven software.
By moving away from monolithic architecture where every team involved is all working from the same code base, microservices allow for the architecture to be split in to high cohesion, low coupling services. These services can then be integrated together again later. By doing this, your team doesn’t have to deal with working in tandem with other microservices. This is empowering for your business to be able to get a lot done without needing the approval of other teams.
Won’t Microservices Just Spread My Complexity Across Multiple Services?
There is no one-type-fits-all solution. There will never be an ideal architecture, or ideal business enablement because every company is different. At the end of the day, good architecture enables the value chain to be efficient, effective, and maximize operating margins. If it’s not, then it’s bad architecture. A well-structured monolith can still be perfectly good architecture.
However, architecture has evolved over the years (Containers, SOA’s) and complexity will always be an inherent part of your business.
What microservices do is allow for a tradeoff.
Enterprises are trading code complexity for organizational complexity. Monolith architectures can become complicated very quickly, and seeking organizational complexity is an effective way to deal with code complexity. In a recent Thoughtful Software Podcast, Skiplist CEO, Andrew Wolfe described monolithic architecture complexity,
“Even teams that are really disciplined, they still run into issues. It’s really hard to keep a monolith organized, you have a thousand developers trying to develop code on it, no matter how good and disciplined is the leadership of that organization.”
Microservices are not impervious to this either. Fail to set up microservices in a distributed way then they will go the route of SOA’s and bleed together. Organizational complexity does not necessarily mean spreading projects too thin or having them all jumbled together. There are effective ways to deal with organizational complexity.
Netflix solved this problem with a NoSQL database. They use Java for all of their microservices and have enabled microservice deployment and infrastructure tools like Hystrix which has helped them build a phenomenal product.
Software architects should not just be planning across software only. They should also be planning around the right people and processes, around plan to deliver value to your customers, and around how to be compliant for all of these factors to build your system.
How Can I Move Toward Microservices?
For enterprises moving to microservices, it is highly recommended to be done in stages. There is no overnight solution. Trying to rewrite code or implement a bi-modal IT strategy at the same time is challenging. The costs will be overwhelming, stretching teams too thin, and result in failure. To mitigate the risk, move towards microservices one step at a time.
Next, you need robust testing. Software is built over multiple years and the average tenure of software developers is between two and three years. There is inevitably going to be turnover from people who have written the code, know how it functions, and know the project. Robust testing enables you to know how the code works on any given day and this means that it will work the exact same for employee B as it did for employee A who wrote it.
Third, do not try and add new features while you are moving towards microservices. If you must have a new set of features, rewrite them first, test them, verify them, and then write the new feature. This takes discipline at the product and project level. Make sure that you are not trying to rebuild the engine while the plane is flying, it’s going to fail and crash. Land the plane first, and then rebuild the engine, and you are likely going to succeed.
How Can My Startup Embrace Microservices?
Your startup should begin by employing some prescriptive resources. Using Heroku, Netlify, Python, or Django will help accelerate to build and bring value to the market. A startup will be better served by not even worrying about what type of architecture to ultimately employ right out of the gate. The focus should be to maximize speed to the market. Focus on optimization and work to figure out how many features you can ship to customers to validate product value and find market fit.
Essentially, allow yourself the flexibility to make mistakes early on and fix them quickly so that to figure out as much as possible in your product’s learning cycle. Employ whatever tools allow you to do this. Before you even consider a monolith or microservice architecture work on product-market fit.
In Summary
Microservices are ultimately a giant puzzle piece in the whole of distributed technology. In all likelihood, microservices will continue to evolve and become more reliable in the years ahead. If you would like to know more about how Skiplist can help you, contact one of our experts.
