DEVOPSdigest

There is a pattern in the adoption of technologies and techniques where people learn about a new tool, say a hammer, and suddenly all their problems begin to look like nails. When microservices captured the development zeitgeist over a decade ago, for many, they became the solution to most problems. It's the web software equivalent to the Unix philosophy in which you write software to do one thing and do it very well.

This allowed for independent services, which communicated via well-defined APIs, owned by small, individual teams. These could be rapidly developed, easily scaled, and shops could use off-the-shelf services. Still, most importantly, developers had the ability to identify microservices with issues and quickly take corrective action or replace them entirely.

Then came the problems. Orchestrating deployment of many small services changes, all moving at various speeds, raised fears that the versions might not interact well. This caused teams to always deploy all their services at the same time. Team members also created microservices unchecked, experimenting with new and exciting languages or frameworks. And when they left a shop, they left untouchable, black-box services behind.

This made it difficult to identify how services interacted or even where they were deployed. Instead of just spaghetti code, you could end up with quantum spaghetti, with data flung through hard-to-discover portals offering developers no hint at what they might find.

There was one more twist in web services that the Unix philosophy didn't have to take into account. While a Unix administrator can have near complete control over their system, unless vigilantly secured and monitored, microservice-based applications can leave your requests accessible to a wider audience. In a way, it's like placing your wallet on a crowded bar, walking away for an hour, and expecting its content to be the same when you return.

If you're planning to develop a new system, especially web apps, the monolith is where you should begin.

This is why, if you're planning to develop a new system, especially web apps, the monolith is where you should begin. This approach allows teams to build quickly together without creating silos or adding members simply because there's another language in use.

Speaking the Same Language

Geographically separated communities often look very different from one another. A week in Paris is going to be quite different from a week in Mumbai, each having distinct languages, traditions and norms. It's no different when you experience a community of practice. A week in a Java codebase is going to be very different from a week working in Python. Yet, a monolith builds a shared team culture and collective knowledge. And a group working toward a common goal will find this makes it much easier to communicate, plan and understand each other.

Teams may still use small services to introduce new technology because it offers an advantage when it comes to development speed. The ability to choose a programming language for individual services also lets teams optimize features for specific functionalities. Still, with employee churn, shops run the risk of losing control over assets produced by colleagues that end up moving on.

For instance, you might have one developer on a team building apps using Golang, another likes Node, and a third has created ones with a new language that nobody else understands. Any microservice can be written in any language, but if a developer versed in it leaves your shop, and you don't have anyone else with that same skill, you'll be in trouble when one of your client's apps goes down. Plus, with microservice sprawl, your ability to pinpoint problems becomes exponentially more difficult.

This means you either find the right talent in a challenging hiring market and pay a premium, or, bring in someone to oversee, manage and organize all microservices. Either way, it's going to consume a lot of time and money.

A monolithic architecture is a more traditional model of a software program, constructed as a unit that's self-contained and set apart from other applications. It connects everything into one piece and developers make web apps with the same programming language. A cohesive team centered around a monolith will take an organization a lot further without leaving a mess in its wake. It keeps teams in sync, resulting in greater work consistency and an enhanced ability to identify issues and deliver support, all accomplished with greater cost efficiency.

Stacking It Up

The monolith was once a popular fixture in development and why it faded into the background depends on who you're speaking with. Some will say the faster development speed afforded by microservices was the primary reason, others will say it was simply a shiny new object that curious developers could play with rather than taking the same boring approach. Somewhere in between is likely where you'll find the answer.

With market volatility impacting the economy, funding of new software efforts has been curtailed and developers are now being forced to do more with less. The reason why the monolith is making a return is that shops have felt the pain of the deployment and orchestration issues that accompany microservices. Foremost, you've got to have all pieces running the same version of code or are at least compatible ones. If you don't, you'll have tremendous difficulty identifying exactly where a problem is or what might be standing in the way.

The monolith architecture is a full-stack operation that ensures all requests go into one server and return what users need. Separate servers and environments aren't needed for apps to work, greatly simplifying management. You essentially have one big interface for your app and any action you take goes through the same path. You can build a monolith until a problem surfaces, then pull out and optimize that one piece.

The fix is fast, easy and reliable.

Locking It Down

It's important to keep in mind that microservices expand the attack surface for bad actors. While there are ways to intelligently and safely deploy them, it can be complex and easy to get wrong. You must secure both the app and the path that allows them to communicate with each other. More nodes in a system means more ways for intruders to find a way in. This poses particular problems in highly regulated industries, like healthcare and finance, where some actions might not even be allowed and penalties for failing compliance are stiff.

Further, microservices mean you need to be vigilant making security updates and patches for servers and even laptops. And when one comes around, do you take down your app? Proponents of microservices might say you just need to spin up a new version of the service including the update. But again, you've still got to orchestrate all changes, make sure everything plays well together and ensure continuity.

A monolith can handle all of these things and more. Its self-contained, simpler nature inherently provides easier control and stronger protection. Being able to lock everything down so well is the final piece of an approach that allows shops to do more with less. For development pros and business owners, the return of the monolith couldn't have come at a better time.