The Microservice Architecture
June 16, 2016
As the world has become more complex and connected, those of us in the technology space are grappling with the resultant paradigm shifts in the underlying technologies. Obvious Cobol doesn’ t cut it these days, but neither does the more common “modern” monolithic software stack.
Enter the Microservice, an independently deployable service oriented around business capabilities. The loose coupling between services allows for a heterogeneous environment of languages, infrastructure, and data, while cooperating to fulfill the business need.
The concept, in a nutshell, is to break down applications into small services. Each running its own process in parallel or in tandem with other small services. The communication between the services is often through lightweight mechanisms like APIs, with some form of centralized management of all of the services involved. This concept allows for services to use storage strategies or programming languages best suited for the task at hand.
I was talking to an old-timer, a programmer of some 40 years back, and she said, “You know, Jim, this is hardly a new concept. It is one that has simply been redone several times over to meet current technology needs.”
She reminded me of back in the day when some of the first 4th-gen programming languages were hardly on the scene and code for read-write routines, embedded loops, remember to check for divide by zero to escape a SOC 7 error, had to be coded over and over again in each program where needed. The AHA moment came when someone had the great idea to create these as ‘ call’ routines. Place them in accessible libraries and programs could call each one as needed and where needed.
These routines soon went well beyond basic calls and sometimes handed data over to other applications for processing and return. Programming became like a big puzzle of components and all coded in compatible languages. And, every time one component changed, the programs using it had to be recompiled and reinstalled. It was still a great concept for the time and reduced testing cycles as well as run time errors. A step forward in technology.
Those processes were still linear though. They were data driven. If a retailer was running billing for their customers, the program ran sequentially until every customer account was processed. While we still have need for this type of processing, the greater need has become to serve one event at a time from a fire hydrant at full throttle. Flashing forward to the re-morph of the ‘ call’ routine into the ‘ service’ routine and in a much more disconnected but somehow still connected architecture.
Because today’ s retailers are awash in high-volume, high-velocity data coming at them from all sides…eCommerce, for example, has become a driving force of global economics. Business-to-customer sales facilitated by the Internet surpassed $1 Trillion several years ago, according to IBM research, and will soon account for over 5 percent of all worldwide economic activity. eCommerce is a performance-driven platform that requires high scalability, stability and quick response times as the volume of transactions continues to rise.
A microservice architectural style with the right back-end storage strategy certainly takes into consideration scalability, stability, integration with other systems, and quick response times, but it also has its downsides. One being that remote calls are more expensive than in-process calls, as there is inherently more overhead as compared to a single stack. Further, use and management of APIs can bring its own complexity, and should be a key consideration in adopting a microservices architecture.
These are all things that we in technology need to be thinking about if we are going to serve our consumers living in a world that is less and less linear, but more and more interconnected.