IDG Contributor Network: Escaping the application inferno

If you’ve worked in devops for more than a couple years, you’re probably all too familiar with the agony of monolithic apps and the hellscape of spaghetti code.

You know what it’s like. Your business logic is embedded in stored procedures. Your business rules are wrapped up in some magical state of values in the database. When performance stalls, you have to scale the application by throwing hardware at it. You have hardly any unit tests, and what you do have are low quality. Your deployments are manual, happen in the middle of the night or on the weekend and require massive coordinated effort.

You’ve gazed into the abyss. The abyss has gazed into you.

So, you’re thinking about microservices. You’ve heard they’re the best way to build massively scalable and distributed systems. That they speed deployment and make maintenance so much easier.

It’s true. Over the past eight years, Agile, automation, software craftsmanship, and cloud computing have combined to make microservices architecture both powerful and practical. And devops has a big role to play in any microservices transition.

If your organization is considering a move to microservices, they should keep these three principles in mind.

1. Devops or bust

The term “microservice” is often misused. Slapping a RESTful web service on top of an existing database doesn’t make it a microservice. A true microservices architecture involves slicing your application into independently deployable and scalable components, loosely coupled and ideally event-driven.

A poorly designed microservices architecture (as many are) can wind up just as complex and hard to maintain as a monolith.

Success with microservices takes maturity, both in deployment and operations. You need built-in infrastructure to monitor the system and make corrections in real time. Comprehensive automated tests are critical to defect-free deployment. And devops is a must because deployments—and rollbacks—have to be automated and fast.

In short, if you want microservices, devops needs to be part of the package.

2. Monitor everything

From an ops perspective, the big trade-off with microservices is monitoring. You may have now split up the monolith into 20 microservices, but now there are more places for problems to crop up. Most of the time, everything works together like cogs in a clock, but those times something does go wrong, how do you diagnose it and recover from the problem?

The answer is instrumentation and correlation across services. Testing and ops training and process needs to include taking services down and recovering. Your code and ops need to be resilient, not a house of cards, and your testing and operational readiness need to reflect that.

Don’t let devs off the hook, either. They should do operational support and pager rotation for the first month of production. All those little things that ops has to do to keep the system running will seem to automate themselves once the devs are on the hook for care and feeding.

3. Embrace change

Microservices require change to both your technology and your organization. You’re probably prepared for the first but be sure not to neglect the second. If you have a bunch of old school devs who refuse to do automated testing, don’t want anything to do with devops, or insist on bad practices (like the aforementioned business logic in stored procedures), you’ll want to address that as part of your transformation. If you tried Agile, the transformation went well and you’re still in a three-to-six-month release cycle, you’re good to go.

Rest assured, any effort to change hearts and minds well be worth it. When you’re done, you’ll have a flexible architecture that enables small players to compete with the big guys—and the big guys to be as nimble as startups.

So, read up on devops, continuous delivery, microservice architecture, and distributed computing. Get something small working, learn from it, and then extend it. Soon you’ll be building applications at global scale and emerging from your application inferno.