Natalie Lambert, vice president of marketing, Sapho on why developers are decoupling massive system architectures into small, independent functions that loosely work together to solve complex problems.
Although not an entirely new concept, micro services represent the latest evolution of software development. Developers are decoupling massive system architectures into independent functions that work together to tackle complex problems. Each micro service is self-contained and responsible for performing a single operation on a back-end system, such as retrieving a customer record or verifying a person’s credit score.
Amazon was the first company to take a large monolithic system and deconstruct it into micro services. Netflix was next, deconstructing its behemoth software stack, seeking a more agile model that could keep up with 2 million daily API requests from more than 800 different device types. Forward-thinking companies like Google, eBay, Uber and Groupon soon followed. Today, enterprises are abandoning monolithic software architectures to usher in the latest era in systems architecture: micro services.
The result is an army of small services that communicate over a network to seamlessly integrate multiple systems – and an army is much nimbler and resilient than one behemoth programme.
Micro services evolved from a desperate need for simplicity in software design. All too often, software projects succumb to glacial development cycles, project bloat, and escalating costs. That’s because for decades, applications have been designed as top-down monoliths in which all functions are lumped together into a single process, then replicated on multiple servers.
Most are still built this way. The problem is that any changes require updating and re-deploying the server-side application — an unacceptable disruption in today’s fast-paced digital world, where immediacy and perfect functionality are considered basic requirements.
In the early 2000s, service-oriented architecture (SOA) emerged as a solution. By separating functions into distinct units that communicate over a network, developers gained greater flexibility and interoperability between programmes. But SOAs proved difficult to work with, requiring heavyweight APIs and multiple layers that were often riddled with incompatibilities. Though they didn’t solve the problem, SOAs opened the door to new enterprise IT solutions — cloud computing, for one. And it ultimately led researchers at Hewlett Packard Labs, charged with making code less brittle and more robust to change, to pioneer the first micro service architecture (MSA).
Keeping enterprises nimble and responsive
The main difference between an MSA and SOA is scale. Micro services are more granular, keeping protocols lightweight for fast and easy communication. And they’re succeeding where other service-based models have previously failed.
Their biggest benefit is accessibility. Micro services rely primarily on the well-known JSON/REST interface, with straightforward authentication via API keys — usually HTTP or OAuth. Easy to build and deploy, they’re a welcome balm to harried developers struggling to keep up with business software needs.
Micro services help enterprises stay competitive with:
Minimal service disruptions. Because they operate independently from each other, micro services can fail without breaking the whole system. The problematic unit simply bows out while the rest of the soldiers keep marching. They can also be maintained individually, without updating the entire system just to change one set of functions. This allows developers to easily fix bugs and add features without frustrating users.
Incredible flexibility. Micro services aren’t tied to any specific language or platform. They’re free agents that can quickly adapt to fit a system’s evolving needs. That leaves developers free to choose whatever framework is best suited to the project, rather than sticking to one-size-fits-all standards such as XML or SOAP.
More cohesion, less coupling. The more interdependent (or coupled) a system’s parts are, the more difficult it is to use, test, and maintain. Micro services are loosely coupled yet form a cohesive whole, creating a more robust and reliable system.
Easy data retrieval. A micro service can exchange information with any other service in the network — no human interaction or changes to the underlying programme required.
