The Value of Enterprise Microservices with Low-Code

At a glance, the term "enterprise microservices" contains conflicting references to a large scale with the word "enterprise" and a diminutive reference with the word "micro". It makes you perceive "enterprise microservices" as an oxymoron, same as "Act Naturally", "Jumbo Shrimp" or "Original Copy". But oxymoron aside, as organizations move to a BizDevOps way of working and use low-code platforms to develop business applications; enterprise microservices have become a cornerstone for building a truly open, extensible, and reusable solution. The significance of microservices is further evident in the fact that 62% of companies are either using or planning to use microservices.

But what exactly is enterprise microservices? And how does low-code fit in? Let’s break it down.

“Services” in enterprise microservices
Services, APIs, web services, and microservices are all like a rose by any other name – they more-or-less mean the same thing.
A service is a function that allows you to programmatically control a system or retrieve information. For example, a hypothetical “addRecord” API can be used by a program to add a record into a central database. This API is crucial to integrate disparate systems while keeping the records centralized. This example is only one of the many use cases where APIs can solve a major business requirement.

In most instances, references to “services” refer to a web API sent over HTTP(S) protocol. HTTP(S) is the most popular choice for API protocol as it doesn’t require your IT admins to open other ports. Additionally, whenever you hear of REST, SOAP, Swagger, and even JSON/YAML/XML (technically data formats, not APIs), those are all calls sent over HTTP(S).
(I know, web sockets and streaming are APIs as well)

“Micro” in enterprise microservices
The prefix “micro” within the word microservices is an implied architectural best practice for the design phase to “keep it (your API) simple, stupid.” While traditionally microservices only applied to architecture, it is also starting to become interchangeable with service, API, etc. in everyday speech.

The word “micro” acts as an important reminder to combat people’s tendency to over-complicate systems. If you ever had to untangle any platform, system or application that had more than a few years of development, you’ll always find strange architectures, add-on modules, and patches that hold everything together. In most user-facing applications this is a necessary evil as the application evolves and attempts to solve all users’ needs. APIs are also prone to becoming over-architected. However, that conglomerate API would not be easy to understand, navigate, version, document, and implement against. It is instead a best practice to break up one big functionality into many small APIs; giving us the micro in microservices.

Each microservice becomes a function or API governing a consumable module. Complex integration scenarios are still easy to implement by integrating against numerous microservices/APIs. For instance, Google Maps app will help you find addresses, directions, street views and more, but when it comes to a Google Maps API, all the functionalities are broken down into individual APIs.

“Enterprise” in enterprise microservices
While the individual micro nature of service keeps its components small and manageable, the enterprise system that includes all the microservices doesn’t have the same safety net of embedded simplicity.

Like an urban sprawl or ant colonies, all the microservices within an organization form its system of systems. Each software module or company department produces its cluster of microservices tied together by application dependencies, integrations, and API management systems. Following Conway’s law, the architectural structure of the system usually starts representing the structure of the organization.

Some of these system clusters or APIs are only navigable by their creators. Some of them are more developer-friendly in providing system blueprints in the form of API documentation, API definitions, and software development kits (SDKs).

Low-code for enterprise microservices
Now with your newfound (or reinforced) appreciation for the ever-growing messy web of enterprise microservices, you can imagine how in every organization all the interdependencies start taking on a life of their own. These interdependencies make it difficult for companies to experiment and innovate with new applications or even launch a new feature or a product update. While this is not a neat reality, it cannot be ignored or ripped out; but it can be remedied by using low-code to add a layer of abstraction on top of the enterprise microservices web, essentially hiding the messy inner workings to providing the end-users with a clean interface.

The new, visionary applications you built on a low-code platform would have to coexist with the old systems the company is already using to run the business. Through enterprise microservices, Mendix can easily give your new apps insight derived from external existing data and logic. These low-code applications can then digitize the aggregation of data, enforce data validity and respect business logic and ecosystems that are already in place. The new solution can be presented to a user in a mobile app, web form, voice assist or any other medium, and will alleviate the technical requirement that gate-keeps the business users from ERP, CRM, and other enterprise systems.

In conclusion, when breaking down and going over enterprise microservices, I hope to have provided insight into the nuances that go into the two seemingly simple words. The integration and interoperability. The confined scale of a microservice that guards against over-engineered systems. The eventual and inevitable growth of enterprise systems. Most importantly in how this existing ecosystem can still be used to shape future applications to fuel business growth.

Click here, if you want to get more hands-on information on how Mendix supports APIs.

Michael Giller is product marketing manager at Mendix.