Skip to main content

Posts

Serverless Integration Components

Serverless should not be optional, but instead it should be there for all cloud native environments. Of course not all applications should adopt serverless. But if you look closer, the majority of the modules in the application are stateless, often stash away in the corner, that are needed occasionally. Some need to to handle loads that are highly fluctuated. These are the perfect candidates to run as serverless. 
Serverless let developers focus on code instead of worrying about infrastructural setups. To provide this environment, along with proper monitoring and reliable backbone to handle large throughput of events.  
This is what Serverless Integration (Kubernetes based) looks like, 
Everything is based on containers. Why care about the underlying technologies for serverless ? Shouldn’t it all be transparent? If your goal is to host or build on a hybrid/multi cloud that is locked-in free from all vendors, it means there are NOT just developers involved in the picture. You will eventua…
Recent posts

Six reasons why you will love Camel K

Camel K, a project under the famous Apache Camel project. This project totally change the way developers work with Kubernetes/OpenShift cloud platforms. By automating the nasty configuration and loads of prep work from developers. 

If you are an old time developer like me. I did my best slowly trying to adapt the latest and greatest cloud native “ecology”. It’s not difficult, but with small things and traps here and there. I’ll tell yel’ it's not a smooth ride. It’s understandable for emerging technologies. But with the large adoption of cloud, I see it’s reaching a level of maturity, where now we are thinking of how to make things go faster, as well as making it more accessible to the larger audience. 

And here is why you will love Camel K.. 

Real-time coding on the platform When a developer wants to publish their application onto a Kubernetes/OpenShift Platform, they need to first build the app. And containerized the app to have a working image. Then pushing the image to the platfor…

My2Cents - Eight things leads to developing catastrophic cloud native microservices system

More of my two cents, just my thoughts. A quick fun read, not too deep, but worth noting :).

1. Setting the domain boundary wrong


This is a job guarantee tactics, it's endless looping in development and testing for everyone involved in the project without making the service to production! First everything starts simple and gradually find more and more functions, business logic gets added into the microservice, at the end, one even have to rename the whole damn thing. 

Symptoms and side effects 

A growing microservices becomes too fat, or every single microservices in the domain calls your microservice. (Sometime core microservice has the same behavior, but you should not see many of this type of services in a single domain.) This violates the microservices principle of easy, maintainable and agile.Duplication of microservices/code everywhere. Where you find bits and pieces of duplicate code or microservices being copied and deployed into other domains. 

If you get into the endless im…

AMQ Online 101 - What I've learnt from recent AMQ Online Hackfest

AMQ Online, project name, EnMasse. Recently, I've attended AMQ Online Hackfest where the Rob and Ulf the engineering team kindly ask us to take a hack on the new platform. If you don't know what AMQ Online is, it's basically an online self-service (Messaging as a Service) messaging platform for developers/application owners to quickly spin up their own queue and topic without worrying about the scalability, network setting and all sorts of operation setups.

Watch this quick video overview on what is AMQ Online:


Before the hack, they went through the basics of AMQ Online, and here is my take on explaining the basics of AMQ Online. With AMQ Online being the platform to service users, there are obviously two main area of focus for people depending on their roles.  The administration side to spin up and manage the platform, the other side of course is the user end, where they will be requesting for the message services.

Admin does the installation of the platform foundation on …

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…

Fuse - Contract First API Design with Apicurio and Fuse/Camel - Part One

This is part one of my two-article series that demonstrates the approach of implementing contract-first API design using Apicurioand Red Hat Fuse.

It covers how to create an OpenAPI standard document as the contract between API providers and consumers using Apicurio. It also shows how to quickly create mock tests using Red Hat Fuse.

There are two common approaches of creating these APIs.
Code FirstContract First Coming from a old time ESB developer, these are not new. We have been doing this forever. Before, it was the WSDL that define the contract of the service. we were doing a lot more code first, for me it's simply because it's much easier for me to write couple of Java classes and generate the WSDL for my consumer. 

It's often pretty straightforward if the consumer of your application has finalized how they want the service to be like. But you and I all know this is not often the case. So I had to go back to my code, and make the changes accordingly and pray I did not …