Skip to main content

Organizing microservices - Modern Integration

Microservices is probably one of the most popular buzz among my fellow developer friends, and I do like the concept of being flexible, agile and having simply having more choices. But as a person that worked in the software integration space for years, I started to see some resemblance of the old ESB days.

Looking at the problem from ten thousand feet up. A decade ago, we had to come up with a better way of organizing the spaghetti connection in between systems, stop duplicating effort on the same piece of business logic. That is when Service oriented architecture(SOA) became popular. By modularizing services, sharing them among others systems, and organize ways of communication, routing of data. And ESB is one implementation of that, maybe not necessary how it should be done.

I was very fortunate to participate in many of these kind of integration projects, and lead some myself. We worked with various middleware vendors, at the time the solutions was all about ESB. By removing the complex interconnecting logic between systems into ESB, negotiating data model among teams (with application/services leaders), setup WSDL contracts for webservices and adding BPEL processes if needed between calls. And I had seem a fair share of amount of these ESB myself, outside of ESB the everything seems very organized. But lift up the ESB “box” you will find many of them end up with even worst tangled spaghetti code (or diagrams depends on your tooling). And that giant bundle of chaos, then become the bottleneck in delivering changes in enterprise.
(On the side note. This is when I started on the lightweight ESB idea, and how I was introduced with Camel, Karaf, servicemix because it solves my problem of being to independently bundle my integration code and breaking that ESB box into smaller distribution..and so on..)
When the idea of independently deployable microservices came along. This giant monolithic monster with idea of smart pipe where it tries to do too much, like data model definition, process flow, interconnect protocols and data format transform ...etc  and dumb endpoint where services just waits to be activated by events was soon cast aside by developers. The relation between each services  are still messy and the monolithic nature make the cycle of development long and cumbersome. The microservice allows developer to be more agile, who needs that piece of “Integration”. So this where the resemblance of a problem where I once trying to solve :)
And let alone we still need to interact with other services(systems/applications) outside microservices. So learning from past here are the things we know what NOT to do..

  • No more large monolithic bundles application to speed up the dev cycle.
  • Stop doing complex business process inside system integration code
  • Data model shouldn’t be defined in the integration layer, it only leads to extra negotiation between teams.
  • State should not be keeped in the integration layer to allow maximum scalability
  • Create fix complex contracts between services.

And still there are things we liked about the old "integration" way.

  • Organized visualized interconnect view of systems.
  • Patterns that are already defined for integrating applications such as aggregations, separation, normalization of data.
  • Event-based approach. A more reactive way and less coupled ways to integration systems.

And that is why I came up with the layered architecture for microservice. The main goal that I wanted to achieve in the new integration architecture in the modern integration/application development is flexibility. Not only in the scalable way but also allowing developer to make any architectural change with ease.
So first thing first, in the new modern agile integration, the integration code itself should be sorted into different small services that make sense in the business world. And are decoupled and made them to be independently deployable microservices units. Then we can start apply true CI/CD to the integration code. This will avoid becoming a large monolithic ESB.

In order to bring some logical sense to my microservice spaghetti, and avoiding repeating the mistake of taking on too much in one single integration bundle. I have defined four layers for my microservice, so each will have it’s own responsibility making it easier to adopt changes.
  • Gateway layer  Provides simple gateway routing capability such as versioning, dealing with different platform of devices.
Originally I want to divide this layer into two, but decide not to because the gateway pattern has become so popular now, people has the perception of gateway should achieve certain ability. (That is a whole other story I want to talk some other time). That is why I have two separate form of the gateway in my diagram, one represents as green other blue.

It’s all about the separation of concerns. This layer is all about generating putting together what is needed for external API consumption. This is where and when separate application domains tries to integrate with each other. And route to the correct versions of services. And clearly the two major concerns were,

  • Accessing policy rules, versioning of endpoints. (APIs)
    • Sets traffic throttle applying limits and policies
    • Security of  APIs
    • Routing to correct versions
  • Combine, transform return result to client.
    • Citizen developer are the main creators here, they uses the capability provided by each microservice team to put together meaningful service to external clients.
    • Collect, split, or normalized a canonical data format to external users.
    • Translate data output depending on the clients
    • Routing between application domains

  • Composite layer  Important middle tier that handles composition of multiple microservices. They do more complex routing from processing the content data and aggregates/split data and populate the split/aggregated result to other microservices by triggering events or simply passing it. This layer hides the complexity of microservices away from clients.

This layer is probably the layer that does most of the old time integration logic where it is responsible for
  • Composing microservices
    • By calling the API available from microservices, and transforming data as needed between them and routing data to the corresponding microservices based on it’s content.
  • Triggers events within domain
    • I believe strongly that event base does best at decoupling stickiness between each service. And allowing performance at it’s best because of its asynchronous nature. The event bus here doesn’t necessary has to be a message broker, but any forms of Bus.  
  • Enrich contents
    • The content enrichment here should be specific to the format and avoid any business side enrichment when possible.
  • Applying Integration patterns
    • Old integration problem will not just go away in microservices world. By applying proven patterns, we can avoid making mistakes.
  • Caching
    • The REST architecture specifically talks about a caching layer. It make sense for the composite layer to try apply caching mechanism because it’s non business related, but do make significant impact to the performance and fault tolerance ability of the system.  

The composite services should also be included in the application domain, which I will talk about in the basic layer.

  • Base layer   Like the name which is most likely represents the basic components of the system. Handles data retrieval or business logic processing. Each should be independent and self-contained.
Borrowing from the idea of Bounded Context,  in this case logically organized group of microservices into what is called application domain. Where each domain represents separate entities of business functions that shares the same data model, this eliminates the need for doing too much transformation in the code.  

  • Anti-corruption layer - This layer handles interface to legacy application or anything that work against microservice quick and flexible principle. This layer is built in protection wall to your system, by doing the transforming job and translate between two very distinct implementations of the system.  

Till next time! :)


Popular posts from this blog

Red Hat Fuse - Announcing Fuse 7 Tech preview 3 release.

Red Hat Fuse 7.0 technical preview three is out today! On the pathway to become one of the best cloud-native integration platform, Fuse gives developer freedom to choose how they want to develop the integration solution, where they want to deploy it and capabilities to address new integration personas that do not have development experience.
By supporting the three major runtime, developer is free to work on the runtime of their choice.By supporting standalone and cloud deployment, it simplifies the complexity to distinguish between these environments, allowing application to deploy freely among the environment of your choice. All levels of developers are welcome, you can either dive deep into creating customize complex integration logic, or using the new low code platform to quickly build a simple integration. In this Tech Preview release you get it all.
Fuse StandaloneSpring-boot for microserviceKaraf 4 for OSGi loverJBoss EAP for JavaEE developersFuse on OpenShiftPlugins for easy co…

JBoss EAP 6 - 效能調校 (一) DataSource 的 Connection Pool

效能沒有什麼Best Practice, 反正能調整的就那些。 通常,一個程式的效能大概有70-80% 都跟程式怎麼寫的其實比較有關係。

最近我最疼愛的小貓Puji 因為膀胱結石開刀的時候過世了,心情很差請原諒我的口氣沒有很好,也沒有心情寫部落格。

Puji R.I.P.



JBoss 的 SubsystemDatasource WebWeb Service EJB Hibernate JMSJCAJVM 調校OS (作業系統)

先來看一下 DataSource Subsystem, DataSource 的部分主要是針對Connection Pool 做調校。

通常,程式都會需要跟資料庫界接,電腦在本機,尤其是在記憶體的運算很快,但是一旦要外部的資源連接,就是會非常的耗資源。所以現在的應用程式伺服器都會有個Pool 放一些先連接好的 資料庫connection,當程式有需要的時候就可以馬上提供,而不用花那些多餘的資源去連接資料庫。

這就是為什麼要針對Connection Pool 去做調校。

以下會討論到的參數,都是跟效能比較有關係,Datasource 還有很多參數,像是檢核connection 是否正確的,我都不會提到。如果你追求的是非常快速的效能,那我建議你一個檢核都不要加。當然,這樣就會為伺服器上面執行的程式帶來風險。這就是你要在效能與正確,安全性上面的取捨了。 (套句我朋友說的話,不可能又要馬兒好,又要馬兒不吃草的..)

最重要的調校參數就是 Connection 的 Pool 數量。(也就是那個Pool 裡面要放幾條的connection.) 這個參數是每一個應用程式都不一樣的。


Connection Pool 最少會存留的connection 數量


Connection Pool 最多可以開啓的 connection 數量


事先將connection pool 裡面建立好min-pool-size 的connection.

我的建議是觀察一下平常程式要用到的量設定為 min-pool-size 。

My 2cents on the future of Integration - With Service Mesh/Istio and Serverless/KNative

It's been a year and half since I blogged about "Agile Integration architecture" (Gosh, time just flies). With the "microservices" and "cloud-native" hype, I was especially curious on how all these new concept and technology affect us on how to architect the integration systems. If you ever pay close attention to all the latest and greatest news from the Kubernetes community, I am sure you will hear a lot about the new "Service Mesh". And rumor has it that this is how integration can/should be done in cloud native world, but, is that so? Anyone who has ever worked on an integration project would tell you, it's a LOT more COMPLEX and can get worst overtime. I did a talk with Christian Posta in Red Hat Tech Exchange coming from a more comprehensive view of how different Red Hat technologies are applied under different patterns when building integration solutions. In fact he also did a great blog about it.

Since then, another topics has be…