Implementing Microservices in OutSystems I

I will walk about this topic in two separated articles. This first article mainly an introduction to what is a microservice, and the second will mainly talk about how to implement microservices in OutSystems.

Have you ever heard of Service Oriented Architecture (SOA)? Simply put, SOA is an architecture that enables one software to connect with each other. a style of software design where services are provided to the other components by application components, through a communication protocol over a network. In SOA, services use protocols that describe how they pass and parse messages using description metadata. It’s like a game of throw and catch between two software or more, only here, the object is data. Nowadays, it’s rare to find a software that doesn’t need service. For example, when you use Spotify, and you want to share the song you listen to your Instagram Story, this action requires a service. A service here acts as the connector between Spotify and Instagram. Using a Simple Object Access Protocol (SOAP), Spotify sends the music data and Instagram receives the data.

Derivative of SOA, there is a service called microservices. Microservices are a software development technique —a variant of the service-oriented architecture (SOA) structural style— that arranges an application as a collection of loosely coupled services. It is basically a simplified service. What make microservices different?

• Independently deployable
• Organized around business capabilities
• Can be implemented within different programming language, database, or hardware and software environment.
• Services are in small size, messaging-enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and built and released with automated processes.

 Of course, the utilization of microservices bring both advantages and disadvantages. Here are the advantages and disadvantages:

Advantages:

• Reduced Time to POC: Developers can build microservices using whichever tools best suit the business value they intend to provide. Combine that with complete data isolation and you have a formula for hyper-fast prototyping.
• Owned by a Team: By dividing business value into a collection of microservices, a small horizontal team can assume full ownership of a microservice. This empowers and motivates them to deliver an excellent product. By contrast, in large monoliths, developers are thrown from task to task; rarely do they feel their contributions are individually meaningful.
• Scalable: Built and published independently of other application elements, a microservice can scale as needed by the organization (which includes downscaling).
• Reusable: Once built, the microservice is available to any consumer. And as it is meant to scale as needed, a microservice can handle the additional workload as well.
• Fault Tolerant: By isolating both its data and application servers from other components, microservices can fail without causing a full product shutdown. And when they do fail, their independent production cycle allows developers to patch them quickly with minimal bureaucratic oversight.
• Easily Governed: Microservices provide a business value. And they mitigate risk by remaining independent of other components. Therefore, aligning their development with the interests of the organization is inherent in their design.
• Budget-Friendly: Their reduced time to POC, scalability, and independence make microservices affordable to launch and maintain. Their strict isolation helps organizations determine cost of operation for each microservice as well.

Disadvantages:

• Network Dependency: Microservices communicate exclusively over standard network protocols, which means that a network outage or disruption of any kind (often beyond an organization’s control) will interfere with business operations. And, as the number of deployed microservices grows, so does the risk of a network outage putting one of these services in jeopardy.
• Dependency Hell: Imagine hundreds of application components relying on a microservice with an established contract (API spec). And now imagine the microservice team wants to redesign (or even slightly modify) their specification. Not only must the organization coordinate this change across myriad teams, they must also track who always relies on whom .
• Strict Contracts: Speaking more to the point above, developers must be careful to define a microservice API specification robust enough to provide business value long after the initial release. That kind of foresight is rare, if impossible in some organizations, that renders microservices a tougher sell.
• Overhead: Each microservice requires its own DevOps processes. As the number of microservices within an organization grows, so does the amount of maintenance and monitoring required for up-keep.
• Too Easy to Launch: This is a strength-as-a-weakness scenario. The ability to deploy and incorporate microservices so simply can lead to overzealousness. Microservice-ifying everything before an organization fully understands the tradeoffs can lead to a failed or poorly executed re-architecting.