Microservices are an engineering approach and architectural style of computing that is becoming extremely important for organizations wanting to innovate through a stronger engagement with their ecosystem of customers, suppliers and partners. To explain them should it be ‘It’ in lieu of ‘them’ since Microservices is a collective term), let’s say your organization is the sponsoring bank at the US Open. There will be a large number of your customers there unfamiliar with the location. They will need financial services — like an ATM locator or the ability to transfer funds from one account to another. They most likely won’t be paying bills. Your app offers all of these functions but there will be increased traffic on the ATM Locator. The app will need to scale and increase capacity for the locator functionality. In a non-microservices architecture, more capacity would be added to the entire app (costly) or the response time would increase. Not a great experience.
With a microservices architecture, the application can monitor each functional component. It detects the increased traffic and adds new instances of the ATM Locator function as demand requires. In other words, it auto-scales the individual component to meet increased demand. When the event is over it sees the drop in traffic and scales back accordingly. The app would be available the entire time, leaving no gap in user experience. In an age where customers expect seamless digital experiences that work all the time, this is a huge breakthrough and necessary action for anyone offering digital products and services.
Microservices versus APIs
Microservices are often confused with Application Programming Interfaces (APIs) and tend to be used interchangeably. But they represent two very different things.
So what is the difference between microservices and APIs? William A Brown “Bill”, an IBM Distinguished Engineer, professor, and author in his own right, describes it as such, “Think about it this way: Say you’re in a western movie set — one of the ones where the town is set up, but it’s only the façade. So you can see the outside of the buildings, the saloon, the barber, etc. but there’s nothing behind the front of the building. That’s an API.
Now, imagine that you are actually in an old west town — you can see the front of the buildings, but you can also walk inside them and see what is going on. That part — the next step behind the façade — is where microservices come in. Microservices are the next part of the architecture, a tier of the backend closest to the façade. To build a great application, you need both — the backend and the façade. They work together, but they are not the same thing.”
Microservices address common application portfolio issues faced by many enterprises.
Enterprise CxO leaders who need to participate in the Digital Economy, must capitalize on new channels and sources of revenue to meet the demands of their business. They are faced with the need to revitalize their core systems and put in place an omnichannel environment that leverages multi-speed IT. Today however, most CxOs are hampered by existing brittle application monoliths, skills gaps, and non-collaborative business and IT operating environments with cultural misalignments. Clearly, there is a lot of work to do, The use of microservices exposed thru APIs, will enable Digital Leaders to meet increased business demand, quickly add new functionality, make changes to and maintain existing functions, and bring products to market in a timely fashion. This style of development and architecture accelerates delivery by minimizing communication and coordination between people, while reducing the scope and risk of change.
So, why do companies — and specifically financial services companies — need microservices?
Brown continues, “Financial services companies have always been looking for speed, execution, flexibility, scalability and reliability, as well as a reduction of complexity. Seem like a tall order? This aspirational future is essential in the digital era that demands rapid change, delivery and customer centricity to win and keep market share. When a microservices architectural style is used to develop greenfield applications, or refactor existing application monoliths, financial services companies position themselves to achieve their lofty goals. They position themselves to take advantage of cloud technologies and services (on prem, off prem, hybrid), and they enable a leaner, efficient IT environment that helps them become a digital enterprise.”
Building beyond the end user
But the benefits extend beyond the user experience — for the enterprise itself, there are many. In addition to being able to serve customers without outages, the increased traffic can lead to generating more business. This could mean more customers and the ability to conduct more transactions, which means greater revenue. Building with a microservices architecture can also save time and money in development.
Bill Brown points to an example of work he oversaw at a large Financial Services company. “The company average time to develop and deploy new digital products was 8 to 12 months” he continues, “in today’s market, that’s just too long. Using this new architectural approach, we were able to reduce that time and deliver new product in 3 months.” Not only does this save money, it decreases the time to market. This is a huge advantage. Afterall, speed to market differentiates the market leaders from the followers. Microservices paired with APIs are essential to getting to market first, but also to getting to market with things that work — no matter what the demand. For those unable to transition using microservices, it will be incredibly hard to stay competitive…”
By Beth Desmond
Beth is a seasoned Corporate Storyteller working with IBM Subject Matter Experts to create unique and provocative Points of Views illustrating how IBM is helping clients globally and across industries. Beth has worked for The Economist as well as Accenture, PWC and most recently Capco, after having begun her career as a commodity derivatives trader.
