Source: zdnet.com
The idea behind microservices and a microservices architecture is relatively simple: hide all the complexities of hardware, operating systems, and different development toolkits behind a standard ‘service’ that is available on a network.
Perhaps the simplest way to illustrate this is with an example. If you click this link, you’ll access Zippopotamus, an open project microservice that provides information about US Zip Codes (roughly equivalent to postal codes outside the United States). Like most microservices, the result is returned over an application programming interface (API) in a standard format called JavaScript Object Notation (JSON) that’s relatively easy for humans and various programming languages to interpret. What’s interesting is that you don’t need to know anything about how this individual microservice works. It could be running on a massive supercomputer, or a room full of people who furiously open books and quickly type results; all that complexity is hidden, and irrelevant to the person or program using the microservice.
If you consider the implication of this, what technical folks call an ‘abstraction layer’, the power of microservices quickly becomes apparent. If the providers of this microservice completely change the hardware, programming language, or physical location of their data center, the user of that service is completely unaffected as long as it continues to return the expected results in the same format. For an internal software application, you no longer have to worry about the painstaking and expensive work of rewriting interfaces and complex connections between systems if they are delivered by microservices. If you have a set of standardized order management microservices, it doesn’t matter if your order management infrastructure is on a mainframe running a COBOL application on Monday and a modern ERP system on Tuesday: the microservice should still deliver the same results, and that change will be seamless to any other application that uses that service.
How to take a microservices approach to application development
Microservices can be leveraged either as a consumer, or a provider. In the zip code microservice example above, you became a consumer of that service by clicking the link and seeing the response data. Zippopotam.us is the provider of the service and maintains the infrastructure that delivered the zip code information, and also publishes documentation on how to use the microservice.
Consuming microservices is probably the easiest way start using them in your organization’s software architecture, as there are thousands available that can do anything from delivering random dad jokes, to providing the location of nearby hospitals, to tracking packages. Most modern consumer applications, and increasingly business applications as well, are little more than a user interface and some high-level logic that manages the interaction among multiple microservices to accomplish a task. Many of these different services require registration or ‘keys’, and some require payment past a certain point, but the costs are usually tiny versus building and maintaining your own code, and the ‘free tier’ are often more than sufficient for a software developer to experiment and learn.
As your developer teams increase their understanding of consuming and building microservices, they’ll start to identify key services that your company can deliver, either internally or externally. For example, you might create an internal microservice that provides customer information that can be used by your call center, shipping applications, and customer support teams. You might consider a public microservice that provides product information, order status, or other functionality that allows third parties to use your products or services in applications they create, or lets partners easily connect with your back-end infrastructure quickly and easily.
Integration tools like MuleSoft, Boomi, Jitterbit, or other tools often called ‘ESBs’ (Enterprise Service Buses) can help speed up the process of creating microservices for your systems.
Avoid these common mistakes when using a microservices approach to software development
Perhaps the biggest pitfall of microservices is forgetting about the ‘micro’ part of the equation. It can be tempting to create an individual service that performs dozens of tasks and acts more as a handoff between legacy systems than a service that performs a discrete task. When you create these ‘monsterservices’ they’re generally only useful in a limited number of applications, versus small, generalized services that can be used in dozens of places.
If you must create a complex, multi-stage service, start by creating simple services that you can combine. There’s no shame in an individual service that calls multiple services to perform its job, and by creating smaller building blocks, you’ll ultimately have more reusable and scalable options in the long run.
The other common pitfall is creating services that are designed for a single application. For example, if I need a tracking number for an order, it might be tempting to create an Order Tracking Number microservice that takes in an order number and returns the tracking number. Better to create an Order Data microservice that provides general information about the order, including the tracking number, that can be used in multiple applications.
Adopting microservices as part of your technology stack
Businesses of all sizes should consider using microservices rather than custom code when available. In fact, microservices have leveled the technology playing field to a large extent. Small businesses were once at a severe disadvantage to the ‘big guys’ that could afford large data centers and the staff to run them. Now, organizations of 1 or 100,000 people can access the same Amazon and Google APIs and leverage the assets of these tech giants. For smaller businesses, microservices can serve as a ‘force multiplier’ in that they allow you to quickly build complex applications by using services that someone else builds and maintains. Thousands of startups have even combined existing services creatively, or built services to fill a specific niche, and turned them into a business.
Larger businesses should consider an investment in microservices as a way to ease their dependency on proprietary and legacy systems. By providing internal microservices, they’re no longer dependent on a particular hardware or software vendor and can upgrade components of their infrastructure without affecting large swaths of applications. Additionally, using microservices allows for legacy data and systems to power creative new tools. With the right microservices, you can quickly develop a mobile app that securely and easily access data formerly locked in a mainframe. Microservices also can reduce the dependency on IT for new tools and applications. If marketing wants to launch a new product catalog and you have a microservice, they’re no longer dependent on IT to write interfaces or provide scarce resources.
Microservices can seem complex and confusing, causing too many IT leaders to regard them as a nice idea that they’ll explore ‘eventually’. As you’ve seen above, they can be as simple as clicking a link.
