Runtime framework
The value of a microservice architecture is well established by many enterprises in case studies. The use of microservices has allowed enterprises to reach larger audiences and successfully address problems with high availability and scalability. What is less published, however, is a coherent approach on how to go about implementing a microservice-driven technology stack.
Most microservice frameworks are built on top of programmatic runtimes, such as Node.js, or as a compiled application produced using a strongly typed language, such as Java or Golang. Whilst this approach is technical sound, it calls for a significant investment in engineering resources to provision and deliver basic elements expected of a microservice environment. Additionally, key features that impact your DevOps team productivity are not readily available without additional software integration or bespoke development.
Enterprises well-versed in the development of monolithic development systems often struggle to adopt a microservice architecture, not for lack of willingness or conceptual information available to digest but more because there is a deficit of tooling putting together all the elements required to build a microservices runtime. Instead, they are facing the prospect of inventing the whole toolchain from scratch. The result is that it often takes many months to realize a solution on how to assemble disparate technologies and tools before any deliverables are realized.
Let’s elaborate on this premise by looking at what is the minimum set of capabilities to operate a credible microservice runtime:
-
Synchronous communications mechanism with REST APIs being commonplace.
-
Script engine to handle API requests and build internal business logic.
-
Storage typically in the form of a private SQL or key/value database.
The above pattern addresses a core minimum of capabilities. However, to make the development of microservices realistically possible, a runtime with a range of additional system capabilities is necessary. These include synchronous (HTTP) and asynchronous (events) messaging mechanisms, code scripting, workflows, scheduled jobs, private database storage, user and messaging security, integration to cross-cutting concerns (email, notifications), centralised logging, alerting as well as the ability to administer the service and deploy it in a containerised setting for its automatic scale-out. The above introduces multiple moving parts and increase the risk of failure as your team embarks on a knowledge acquisition journey to absorb multiple new technologies and tools.
Neptune DXP helps mitigate these risks by packaging all the ingredients necessary to start your microservice development straight away without incurring unnecessary boilerplate development: