Microservices are the next step after SOA—services implement a limited set of functions. Services are developed, deployed, and scaled independently. This way, you get shorter time to results and increased flexibility.
Microservices have to be independent regarding build, deployment, data management, and business domains. A solid Microservices design requires single responsibility, loose coupling, and a decentralized architecture. A Microservice can to be available within an enterprise or open to partners and public via APIs.
This blog post contains a slide deck, which discusses technologies such as REST, WebSockets, OSGi, Puppet, Docker, Cloud Foundry, and many more, which can be used to build and deploy Microservices. The main part shows different open service frameworks and commercial tools to build Microservices on top of these technologies.
Key Messages: Integration, Real-Time Event Correlation, TCO, Time-to-Market
Microservices are not easy to realize in a “legacy environment.” A lot of modern concepts, technologies, and organizational changes are required to be successful. Three key messages describe the complexity and variety of Microservices:
– Integration is key for success of Microservices: Microservices use smart endpoints and dumb pipes. Nevertheless, these Microservices have to communicate with each other. Integration has to be implemented somewhere. Coordination services are required, too. Besides, Microservices is not just REST! Messaging is getting more and more important in Microservices architectures. Big Data, Mobile Devices, and Internet of Things need other technologies and standards for communications than synchronous request-reply via REST. Modern messaging standards such as WebSockets, MQTT, AMQP have to be used.
– Real-time event correlation is the game-changer: Microservices are independent. Nevertheless, the real business value is created by correlating events of different Microservices. Proactive actions and predictive streaming analytics use information while data is in motion. When data is at rest, it is too late in many use cases. Automatic, real-time event processing is the key for success. On top, you might need human interaction using a live data mart to see events pushed into a UI in real time and act proactively within the UI (e.g. by sending an alert, starting a business process or creating a new event for further automatic processing in the event server).
– Total Cost of Ownership (TCO) and time-to-market are major aspects for tool selection: Of course, you can code everything by yourself. However, adapting new requirements in a quick and agile way is a basic idea behind Microservices. Think about the business value and total cost of a project before choosing a framework or tool. Try frameworks and tools out by yourself. Do a POC (proof of concept) to demonstrate time-to-market with both open source frameworks and commercial tools.
Slide Deck: Tool Selection for a Microservices Architecture
I had a talk at Karlsruher Entwicklertag 2015 in Germany to discuss how to choose the right technology, framework or tool to build Microservices. I used the above three key messages throughout my presentation. Here is an extended version of the slide deck:
TIBCO Portfolio for Microservices
As you can see in the slide deck, TIBCO’s portfolio is a perfect match for a modern Microservices architecture. “A Complete Guide to TIBCO: Microservices and DevOps” explains the relation of TIBCO products and Microservices in more detail. Or do you wonder if “a Good Microservices Architecture = Death of the Enterprise Service Bus (ESB)?” What do you think about the buzzword “Microservices”? Tell me! Let’s discuss!
