Cloud-to-Cloud integration is part of a hybrid integration architecture. It enables to implement quick and agile integration scenarios without the burden of setting up complex VM- or container-based infrastructures. One key use case for cloud-to-cloud integration is innovation using a fail-fast methodology where you realize new ideas quickly. You typically think in days or weeks, not in months. If an idea fails, you throw it away and start another new idea. If the idea works well, you scale it out and bring it into production to a on premise, cloud or hybrid infrastructure. Finally, you make expose the idea and make it easily available to any interested service consumer in your enterprise, partners or public end users.
The following shows a case study about successfully moving from a very complex monolith system to a cloud-native architecture. The architecture leverages containers and Microservices. This solve issues such as high efforts for extending the system, and a very slow deployment process. The old system included a few huge Java applications and a complex integration middleware deployment.
The new architecture allows flexible development, deployment and operations of business and integration services. Besides, it is vendor-agnostic so that you can leverage on-premise hardware, different public cloud infrastructures, and cloud-native PaaS platforms.
Like every year, I attended JavaOne (part of Oracle World) in San Francisco in late September 2016. This is still one of the biggest conferences around the world for technical experts like developers and architects.
I planned to write a blog posts about new trends from the program, exhibition and chats with other attendees. Though, I can make it short: Besides focus on Java platform updates (Java 9, Java EE 8, etc.), I saw three hot topics which are highly related to each other: Microservices, Docker and Cloud. It felt like 80% of non-Java talks were about these three topics. The other 20% were Internet of Things (IoT), DevOps and some other stuff. Middleware was also a hot topic. Not always directly, but I was in several talks focusing on integration, orchestration of microservices, (IoT) gateways.
[Originally posted on the TIBCO Blog]
The IT world is moving forward rapidly. The digital transformation changes complete industries and peels away existing business models. Cloud services, mobile devices, and the Internet of Things establish wild spaghetti architectures through different departments and lines of business. Several different concepts, technologies, and deployment options are used. A single integration backbone is not sufficient in this era anymore.
A hybrid integration platform for core and edge services
I was invited to speak at Microservices Meetup Dublin this week. I updated my slide deck “Microservices – Death of the ESB?” … The meetup was fully booked with a waiting list; around 120 attendees came to Gild‘s office. (see attached link).
If you have not seen the slide deck last year, you should definitely take a look at this updated version with more recent information. I also incorporated valuable information from discussions with attendees in 2015’s sessions about this topic.
[UPDATE June 2016: Please also read this updated article about Microservices, Containers and Cloud-Native Architecture for Middleware]
In 2015, the middleware world focuses on two buzzwords: Docker and Microservices. Software vendors still sell products such as an Enterprise Service Bus (ESB) or Complex Event Processing (CEP) engines. How is this related?
Docker is a fascinating technology to deploy and distribute modules (middleware, applications, services) quickly and easily. Most people agree that Docker will change the future of software development in the next years. I will do another blog post about how Docker is related to TIBCO and how you can deploy and distribute Microservices with Docker and TIBCO products such as TIBCO EMS and BusinessWorks 6 easily.
Last week, I gave a talk at a German conference (Karlsruher Entwicklertag 2015) about Microservices. The following slide deck shows plenty of different technologies (e.g. REST, WebSockets), frameworks (e.g. Apache CXF, Apache Camel, Puppet, Docker) or tools (e.g. TIBCO BusinessWorks, API Exchange) to realize Microservices.
Abstract: How to Build Microservices
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.
These days, it seems like everybody is talking about microservices. You can read a lot about it in hundreds of articles and blog posts, but my recommended starting point would be this article by Martin Fowler, which initiated the huge discussion about this new architectural concept. This article is about the challenges, requirements and best practices for creating a good microservices architecture, and what role an Enterprise Service Bus (ESB) plays in this game.
Branding and Marketing: EAI vs. SOA vs. ESB vs. Microservices
Let’s begin with a little bit of history about Service-oriented Architecture (SOA) and Enterprise Service Bus to find out why microservices have become so trendy.
Everybody is talking about Microservices these days. You can read a lot about Microservices in hundreds of articles and blog posts. A good starting point is Martin Fowler’s article, which initiated the huge discussion about this new architecture concept.
For an overview about requirements for a good Microservices architecture, also read this article: “Do Good Microservices Architectures Spell the Death of the Enterprise Service Bus?”
Another great resource is an free on-demand webinar by vendor-independent analyst Gartner: “Time to Get Off the Enterprise Service Bus“. It does not even mention the term “Microservices”, but explains its basic motivation and concepts.
In October 2014, I had a talk at Jazoon in Zurich, Switzerland: “A New Front for SOA: Open API and API Management as Game Changer”
Business Perspective – Open API and API Management
Open API represent the leading edge of a new business model, providing innovative ways for companies to expand brand value and routes to market, and create new value chains for intellectual property. In the past, SOA strategies mostly targeted internal users. Open APIs target mostly external partners.