Microservices Architecture: Future of Enterprise App Development

2015 marked a turning point for most enterprises. With the rise of Bring Your Own Device (BYOD) trend & growing adoption of fast-performing mobile apps among both employees and customers, businesses could no longer ignore the importance of being tech-savvy and started investing in software development.

They were bound to hit a bump in the road, of course. According to Agnes Sheehan, Telstra’s director of connectivity and network sales, companies that integrate new applications into their software ecosystem often fail to keep the apps updated, secure and running seamlessly on every device in the workplace. In fact, 25% of business systems employed by small, medium-sized and even Fortune 500 companies are subject to 700+ vulnerabilities.

Google and Apple roll out software updates on a regular basis — and we are used to it. Why do most companies lag behind the tech tycoons?

· Software complexity. Customer Relationship and Content Management systems, Document Management Software, Enterprise Resource Planning solutions and other applications used for business purposes support a wide range of functions including distributed use of the centralized database, report generation and content creation. These applications are monolithic by nature and function as a whole. If you run an insurance company and want to update software modules that deal with auto insurance only, you’ll have to upgrade the rest of the system as well;

· High software development & maintenance costs. Last year enterprises spent $ 620 billion on process and desktop applications, while IT services spendings reached $ 520 billion. Even if you outsource software development to an offshore company, be ready to pay $ 35 for an hour’s work (experienced developers don’t come cheap). Gartner claims application updates cost up to 30% of the original software price;

· Software availability. In a world where everything is automated & superfast, your customers won’t tolerate the “currently not available” banner for long. And don’t forget about bugs, too.

And what if you could cut a bulky enterprise application intopieces like a birthday cake and upgrade these modules independently? That’s what the microservices architecture approach is about.

What is microservices and why should you care?

Although Service-oriented Architecture (SOA) and microservices do have a lot in common, they are not one and the same thing. While SOA is a software design pattern where components of an enterprise application “talk” to each other using communication protocols, microservices enable developers to build apps as suites of independently deployable services.

What makes microservices different from traditional monolithic applications?

If you build an ordinary custom enterprise application, you decide on its functionality and tie these capabilities together. The app components run simultaneously, so you have to install it on every computer in your office.

With microservices, each capability (report generation, document management, customer relations) can be treated as a separate process. There’s no middleware; instead, the services use communication protocols (typically REST since they are less complex). Also, you can put different services modules on different machines, so there’s no need to install the whole app on all the devices within your business computer network.

Benefits of the Microservices App Architecture

· Easier upgrades. A monolithic app contains many components (functions) that are employed through third-party/native libraries and a programming language. You can upgrade these libraries, and — hopefully! — it won’t affect the app’s overall performance to a large extent (you can’t be sure though). However, you cannot use Java 8 if your library supports Java 7 only without doing some major re-coding. Microservices, on the contrary, communicate through messaging/web service calls, often use different tech stack and can be upgraded with no impact on the system;

· Focus on business capabilities. Traditional enterprise application development revolves around technology (UI, UX, server, database, etc.), so vendors have a limited choice of dev tools to implement certain app functions. Microservices center on business tasks (catalog, shipping, order placement). You may opt for any tech tool — it’s the end result that matters;

· Infrastructure automation. Using Blue/Green Deployment tools, you can significantly reduce the time between getting an app done and putting it to work or even automate your software delivery cycle;

· Perfect for going multi-platform. Applications that use microservices architecture can seamlessly run on multiple devices, including PCs, smartphones and wearables.

What’s next?

Netfix became one of the first companies to adopt the microservices technology in 2012 after a missing semicolon almost brought the whole system down. They disbanded their traditional software development team (100+ developers) and created multiple small teams that support hundreds of processes running within the application. Every microservice has a separate data storage solution, so there’s no need to update services individually if the company makes significant changes to its database. Netfix also adopted the continuous delivery model and now releases minor software updates on a regular basis. Thanks to microservices, Netfix can quickly respond to customer needs and deliver innovative experience, thus gaining a competitive advantage over their rivals.

Amazon, Ebay, PayPal, Gilt, Guardian and many other large-scale websites and applications have evolved from monolithic to microservices. Does it mean the future of software development lies in microservices?

Martin Fowler, a notable software engineer and outspoken microservices advocate, urges companies not to follow the trend blindly. In order to successfully maintain a microservices ecosystem, your company should do rapid provisioning, monitor services’ performance, automate software deployment and embrace the DevOps culture. When in doubt, make sure to consult an experienced vendor. Sometimes it’s better to build a monolith first, test the waters and split the application into microservices when it gets too large to maintain.