How do you code a microservice? How do you connect the microservice with other microservices? How do you debug a microservice? How do you build a microservices architecture that supports independently iterating each service?
To date, engineering organizations adopting microservices have had to build bespoke infrastructure on top of existing web application frameworks such as Rails, Flask, Spring, or NodeJS to support microservices. This infrastructure addresses two changes with a microservices architecture:
- Microservices interact with other services. A single request can be processed by many microservices. Log data spans multiple microservices. Monolithic applications are designed to operate as solitary entities.
- Microservices are updated with much greater frequency, making testing and reliability much harder. New microservices, and new versions of microservices, are constantly being updated as different teams develop, test, and ship on independent release cycles.
Today, we’re excited to announce two products that enable any organization, regardless of size, to start adopting microservices right away. With Datawire, you can start shipping features as microservices in minutes, not months.
Announcing the Microservices Development Kit
Today, we’re releasing the beta version of the Microservices Development Kit (MDK), an open source SDK for building microservices. The MDK contains all the infrastructure your microservice needs to interact with other services, including service registration, distributed tracing, and circuit breakers.
@app.route("/") # Flask handler for our simple service def hello(): return "Hello World!" if __name__ == "__main__": # initialize the mdk and register our address m = mdk.start() m.register("hello-world", "1.0", addr) # register a shutdown hook for timely exit notification atexit.register(m.stop) app.run(host=host, port=port)
Announcing Mission Control
We’re also announcing Mission Control, a cloud-based service that helps you manage and monitor multiple microservices. When microservices are being constantly updated, you want an infrastructure where a single software bug is not catastrophic to your application so that you don’t need to slow down the iteration of any given team.
Mission Control limits the impact of any given software failure, and, when a failure occurs, gives you the visibility you need to quickly root cause the failure. Mission Control gives you:
- Protection against software failures, with automatic client-side blacklisting of bad microservices
- Distributed log tracing for debugging interactions between microservices
- Eventually consistent, highly available service discovery
- A real-time view of your available microservices and versions
Software resilience, not just server resilience
With Mission Control and the MDK, your cloud application gains resilience from software bugs, and not just server and network failures. This is critical as updates are pushed with high frequency in a microservices architecture. For example, imagine a new update to microservice Alpha changes the semantics of a specific API. Testing of Alpha by itself reveals no issues, Alpha is deployed into production. Another microservice, Beta, invokes the updated API, and throws an exception. The root cause of the failure in Beta is a bug in Alpha – yet the exception is logged in Beta.
With the MDK and Mission Control, such a bug would cause the new version of Alpha to be blacklisted by Beta. Beta would log the exception and propagate that exception to Mission Control, which would show a full trace of the entire request that spans Alpha and Beta, making it easy to identify the root cause.
Create a free account
We’re releasing the MDK and Mission Control for public beta today. Create a free account and get started with a microservice in minutes. The first 50 people who sign up and connect a microservice will receive a micromug!