Microservices for Non-Engineers
Everyone has “that box.”
You know — that box: the one in the attic or the garage or the shed out back; the one in a storage unit or tucked under a pile of clothes in a bedroom closet; the box you’ve been dumping stuff into for years because you tell yourself, “you might need this someday”; the one whose contents have grown so jumbled, random, and disharmonious, you’re not really sure anymore what’s even in there.
There is a problem with that box. Okay, maybe several problems. But the core problem we’ll start with is the nature of this box as a giant bucket for many different kinds of things.
This nature raises several questions, each with its own implicit set of potential compounding problems. How important is classification? Is it just a pedantic exercise or does classification serve some useful purpose? If we have a big box of things, how important is it to sort through the box and move the various kinds of things into more purpose-specific containers? If we don’t see obvious relationships between some of the items in the box, is it important to preserve the ability to bring them together later — or is it okay to silo them away from each other in their separate, purpose-specific worlds?
As many people in enterprise IT know, businesses have a version of “that box” of their own — legacy software.
In recent years, some companies have begun asking questions similar to those above in order to sort out the content of this IT box. Legacy monolithic systems rely on software architecture approaches in which all of the diverse functions which comprise an application are bundled into one giant box. This style of building applications has offered some advantages, such as fewer dependencies on external pieces of software, but monolithic applications also incur a cost — namely, that they are complex beasts that must be built by large, slow teams; deployed in one heavy monolithic box; and updated only carefully and slowly (just like that box in the closet or shed becomes increasingly difficult to keep organized as it absorbs new additions).
This approach to software development could get out of hand quickly for large-scale applications that serve many users. What if just one small portion of the monolithic application needed more resources like memory or processor time? Well, generally, you would need to deploy a second heavy box — and everything that comes with it — even though the actual requirement was much more finite.
As companies have explored this problem, a solution has emerged: break these monolithic applications into smaller chunks, each of which handles one specific point of functionality. In other words, instead of deploying one giant, heavy box, these companies are now deploying many small boxes.
By replacing a big box with many small boxes — or replacing a monolithic service with many microservices, in IT parlance — an enterprise can enjoy many advantages. Each microservice can be built by a small team, sometimes only one or two people, in little time. This shift allows for rapid development, prototyping, and iteration — and for the agility to more easily pursue new business opportunities and ways to engage with customers.
This modularity makes microservices ideal for UX, or user experience — the visible part of any application. In the monolith age, innovating based on a specific piece of functionality could be difficult because the functionality was encased in the big box, and if a developer made changes to that functionality, they might break some other part of the box’s contents. With microservices, though, individual boxes can be freely replaced, updated, rearranged, and recombined, vastly increasing the optionality a business enjoys to leverage its technical assets.
Microservices are also scalable individually — that is, the ability to serve up a given tiny box in an end user experience isn’t dependent on the ability to serve up any other boxes that comprise that experience. A retail application might include one microservice that resides in its container and provides geolocation and store location functionality, and the application might include another microservice, residing in its own container, for looking up customer information.
This individual deployability and scalability can be crucial. Suppose an application becomes popular and suddenly its performance begins to degrade. In the monolithic architecture, you would need to deploy multiple heavy boxes, each containing not only the little piece that needed replication but also everything else that didn’t need to be replicated. Very inefficient. Very expensive. With microservices, you only scale the pieces that require it.
Think about your own personal box. Let’s say it contains all of your arts and crafts supplies — paints, glues, glitters, tracing paper, construction paper, canvases, brushes, pens, pencils, stamps, ink pads, scissors, and everything else you’ve collected over the years for your creative endeavors. Just looking at that variety of items is likely enough to dissuade many people from even diving into the mess and trying to locate the items needed to create something. Wouldn’t it be easier for you to have multiple small containers, each holding a single type of arts and crafts supply?
And wouldn’t it be insane if you needed to add just a few more pens but had to replicate the entire box in order to do so? When you go crazy collecting fancy pens, you should only need to buy a few pen holders, not duplicate your entire art supply — and when a microservice goes nuts because lots of customers are using the applications that rely on it, a business should only need to spin up new versions of that lightweight microservice, not deploy entire fat applications over and over again.
Speaking of classification, it bears mentioning that microservices are not some “new type of thing” in software architecture so much as another type of service in a business’s IT ecosystem. This means the value, optionality, and impact of these microservices can be enhanced by applying the same security, logging, monitoring, and service management tools used elsewhere in the ecosystem. Developers typically consume services — including microservices — via application programming interfaces, or APIs, so the API management tools used to connect applications, data, and systems throughout the organization can also apply control and visibility to microservices. Though microservices may also require more specialized management tools for service-to-service communication, such as a service mesh, microservices fit into many of the management tools most businesses are already using.
In short, microservices are simply a better method for packing and deploying boxes. They allow for quick development and quick enhancements to user experience. Working with an API management layer, microservices are a powerful ingredient for building modern experiences that your customers have come to expect.
[Looking to learn more about microservices? Get your copy of our recent eBook, Maximizing Microservices.]
