How I stopped worrying about microservices and learned to love the monolith

Stop building legacy and letting your tech fall behind. Do this instead.

Business cares about the bottom-line, and rightly so. But that often means that technology falls behind. We have large industries being run by core backend systems that haven’t been touched for decades. This is fine for keeping things running as they are, but totally disregards the risks of building up technical debt.

The risks that often surface include dependence on specific skill sets such as SAP/Salesforce, as well as reliance on a specific core system to keep the business running in the first place. SAP/Salesforce down? No sales while the team tries to fix it.

With old tech, there is next to no agility to innovate. When the organization wants to add new innovative services/features, it must deal with the constraints of the current system and spend large for every small step forward.

In this day and age, an ideal business should strive for values like:

• Business service availability
• Ability to make use of MvP’s and POC’s to enable quick feedback loops on assumptions
• Constant drive for cost reductions
• Constant innovation with minimal time to market
• Using raw data for insight
• An internal culture of constant innovation using new technologies based on insights.

In this post, we will share how we proceed from an organization (let’s call it ACME) reliant on a legacy core or monolith to an agile and fast-moving organization that constantly seeks innovation.

How do you get to that place, and what should you address first? After that, we will cover 3 cases in which we used these methods to help the organizations and steer the ship towards agility.

Start with the culture

“The road to hell is paved with good intentions”

Organizations don’t just find themselves in these situations, nor is there anyone to blame. Rather, we believe that people in general are well aware of these issues but, depending on their appetite for risk and goals, prioritize upping internal metrics that could mean promotion. Conway’s law demonstrates this perfectly:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

The organization will put forward a design that represents what its management structure and day-to-day culture looks like. The communication structure defines the boundaries inside the organization and thus determines how the services and teams talk to each other. Which leads us to another law, i.e.Jimmy’s Law:

“A broken, dysfunctional organization driven by meeting unhealthy goals and metrics will produce broken, dysfunctional systems.”

Which means that figuring out how an organization found itself in this situation requires looking at the people. Based on what you find, you can then start changing things. We find that when you design the organization the way you want, the architecture will follow (kicking and screaming most of the time).

Get to know microservices

Microservices is the buzz word that has arisen from the principles of Service Orientated Architectures. The idea is simple: small services that allow teams to focus on a single purpose. But they are not the be-all and end-all solution.

Microservices are built with a specific goal and are often the result of pulling a certain functionality out of the monolith. Most organizations start with a single large code base, then begin identifying problems which can be separated into individual components.

This allows organizations to scale out individual components instead of the application as a whole. The real benefit here is that microservices allow multiple teams to onboard small components with specialized technology quickly, instead of having to learn an entire code base with all of its technical debt.

Pick your microservices like this

When looking at your organization and the use of microservices, consider whether they will add business value in any of the following areas:

Depending on your business objective, a microservice must hit one of these. If it does not provide substantial value in that area, you should scrap the idea.

Don’t start with microservices though

But if microservices are so great, why not just start with them? Answer: been there and never want to go back.

Years back, I was in charge of creating an architecture that would allow a newly funded startup to scale up. And why would starting from scratch with microservices not work? Well, we tried it and were easily able to scale up to thousands of requests per second.

Maintainability for a small team fell through the floor. As a startup, you need to move fast and having your entire infrastructure composed of microservices does not allow teams to deploy and create features easily. Every feature requires you to think about how each microservice will affect the others. And this is largely what I put down as our downfall, not being able to move fast enough.

In the end, the company moved back to a simple monolith that is easy to scale and maintain. You should start every new project as a monolith unless you have excellent reasons not to.

This will allow your teams to move quickly and focus on features that can actually be released.

Lesson learned: Boring is Good™.

Decompose your monolith

What often happens is that you already have a large monolith with specific issues. The application was a success and has grown a sustainable business. This is what would be a perfect opportunity, to take a fresh look at your infrastructure with microservices.

For example, management has a clear vision – “Adapt the system to serve larger events”. Starting with this directive, we need to clearly define what supports and blocks this vision:

Are we selling tickets fast enough?
Are we able to handle the load when a big event hits?
What metrics are we currently tracking?

In this example, the blocker was clear. We were selling too few tickets per second, and stadiums would take hours to fill. The page also didn’t seem to be able to handle the load. This sets clear objectives for operations. In this case, our focus would be on SPEED and SCALABILITY, and the return on investment would allow much bigger events.

Following this guide has served us well in finding components and areas with real business value. Feel free to repeat and share your stories.

Lesson learned: Focus on providing value to your business and customer, the infrastructure will follow.

Governance

What happens when a large enterprise with a very old legacy system, often from decades ago, wants to make use of this paradigm? You start with top-down stakeholders. For example, let’s imagine a large enterprise with a 14-year-old SAP installation. The company has various issues and wants to transition to a more agile method that will allow working with more partners, as it’s currently relying on one partner with SAP experts.

Firstly Culture + Governance will play a major role in guiding the organization forward. Stakeholders must be key drivers in pushing this forward. Second, nothing beats good governance.

Looking back at our values:

Speed
Scalability
Availability
Agility

In this example, the team can immediately see that reliance on SAP is a major risk, both for talent and availability. The immediate values to start looking at would be AVAILABILITY + AGILITY.

AVAILABILITY to eliminate reliance on SAP, since when the central storage goes down, the entire organization grinds to a halt. Business value is huge here, allowing the business to continue taking orders until the SAP system is fixed, should anything happen.

AGILITY to work with multiple partners and have features take days instead of months to implement using new, fit-for-purpose innovative technologies.

The ideal architecture in this situation would be something along the lines of:

Which is easy enough to draw on a graph, but mobilizing an entire organization with multiple departments is something else entirely. For these large change management projects, you need governance guiding how the organization works.

In this case, we highly advise these three core components:

• Technical Design Committee
• Management Service Partner (MSP)
• Technical partners for projects

Each with very different roles:

• The Technical Design Committee is accountable for approving all contacts with technical partners and representing the organization in them. They report to the company leadership and guide the partners in achieving their goals.
• The Management Service Partner (MSP) should be a partner/stakeholder that manages and sets forth multiple policies for each cloud and provides a basic framework for all projects taken up by the company. This makes auditing easy, as the framework is defined at this level.
• Technical partners now have clear projects and systems they can work with. They can integrate SAP, but get the required abstract services from core services . This allows technical partners to create small projects and services, quickly and in parallel.

Keep following these principles and prepare for a multi-year journey. Many organizations have gone before you and succeeded.

Conclusion

Microservices has become a bit of a hype word and, while they have merit, it should be made very clear that they are not the solution. On the contrary, we advise starting with one big code base and decomposing.

Look at your business goal, your development team size, then your current blockers. Choose your actions accordingly and carefully.