Microservices are your future. Actually, they are your present — or should be. If you’re not already well-versed in microservices and containers, you’re running at the back of the pack. It’s time to study fast and furious.
We’re all used to giant monolithic applications that handle every last aspect of a solution, no matter how small. To be simplistic, think Microsoft Word or Adobe Photoshop. Each does hundreds of different things. Photoshop, probably closer to a thousand. In the case of Word, it’s pretty clear that file management, page layout, spell check, mail merge, and printing have nothing whatsoever to do with each other. So, why are they all shoehorned into one giant program?
To answer my own rhetorical question, it’s because that’s how we’ve done it for decades. Sure, Word runs as a launcher .exe and a handful of dynamic link libraries (.dll files), but that’s for memory management as much as anything else. That model isn’t really any different that the days of yore when mainframe computers were lucky to have 64K of magnetic core memory. To allow large, monolithic accounting systems to function, different modules were often written as a series of overlays, swapped into memory as needed. It was a real art form. Microservices are vastly different.
In a microservices architecture, large, complex programs are built from small processes that are each independent, communicating with each other — when necessary — through application program interfaces (APIs). Think of it as a suite of small, non-coupled modules, each running in its own little world.
The advantages are profound. Microservices solves the update problem. With a traditional monolithic application, a new version usually means replacing everything. Not so in a microservices architecture, where individual pieces can be updated as necessary. That’s especially useful with cloud and mobile applications where, for example, weekly user interface or functionality updates are fast becoming the accepted way of doing business.
Second is the issue of demand scalability. Should one aspect of a monolithic system become a bottleneck, say, checking inventory levels in a retail application, there’s no simple way to add capacity. But, in a cloud application designed as a series of uncoupled, containerized microservices, it’s a relatively simple matter to spin up additional instances to meet demand and alleviate the bottleneck.
We’ll be doing some spinning up of our own, as SearchCloudApplications writes more about microservices architecture in the coming months.
What’s your experience with microservices? We’d like to hear from you.