A few days ago we at CROZ organized a very interesting event at Cinema Europa. And even though we didn’t watch any movies, the topic could easily fit into a movie: „Cloud Native & Integration – How to Survive the Transformation?” A true Transformer franchise blockbuster lookalike.
Developing software and building modern IT systems according to Cloud Native principles is currently one of the hottest topics in most serious IT businesses. Some of them have already started their transformation, some are planning it, and some are still in the research phase. The path to Cloud Native is not easy, but it’s surely worth it because the improvements it brings in the end are huge.
During the event we introduced our friends and partners from Container Solutions. With offices in Amsterdam, London, Berlin and Zürich the team of Container Solutions went through many Cloud Native transformations within large corporations. Their CTO Pini Reznik talked about some of the largest risks linked to Cloud Native transformations and explained which models, tools and organizational structures can be used to increase the chances of success.
But Cloud Native principles also bring a new outlook on integration, which is why CROZ’s experts Denis Jajčević, Ivan Krnić and Krešimir Musa revealed how platforms like Apache Camel and Red Hat Fuse can help clients on their way to Cloud Native solutions and what role API management platforms like IBM API Connect play in modernization and breaking legacy monoliths.
Since it was a full house, it would only be fair to share the word with the ones who couldn’t make it. Maybe you’ll disagree, but according to my personal choice, these 5 things (there always has to be a number, right?) are the key takeaways from the event. It’s up to you to dig deeper into the ones you like the most.
And for any questions, don’t hesitate to call me. I know people who know people…
1. What do companies want?
Going customer-centric by going fast without breaking things? Sorry boys and girls, this won’t work. In order to push the limit, you need to experiment, which usually means breaking and throwing away some things along the way, we all know that. But there is a way to align waterfall, agile and cloud native activities in order to set up a quality DevOps system. Yes, it hurts because it’s also a cultural effort apart from a technical one, but isn’t it in our core DNA as engineers to continuously improve? Define your vision and make your machine produce value through numerous PoCs within the iterations.
2. How to scale the size of the experiment?
Complete “no regrets” decisions before “big bets”. You should become well-aware and experienced with your team and technology through a series of focused (hard) workshops before making large-scale commitments that come after building up understanding with no-regret moves and hedges. So, if this little thing you call a microservices application works on a small scale of users, this doesn’t mean you are doing the right thing – or doing things right. Unfortunately, it backfires just about then.
3. Leave no friend behind!
Maybe it looks like an architectural issue but in order to succeed, all sides must align. Look at this beautiful maturity matrix. A true mind-changing moment. Even though we start with a wish to build microservices, it’s just a drop in the sea of the important building blocks we need to cherish along the way in order to reach our goal. So, even though you’re not sitting in the same silos, leave no colleague behind!
Also, keep in mind that Automation and CI/CD also go together. You won’t have time for them when production enhancements or business requirements start to pile up.
4. Can ESB and API platforms live together?
Worse things have happened. Of course they can. ESB platforms focus on service lifecycle governance, while API platforms play well in API-centric governance world. Since we’re already talking about ESB-s… Within the context of cloud native – be sure to check the platforms which can function as a distributed ESB, such as Apache Camel or Red Hat Fuse. If your context is closer to a SOA-centric one, then there’s still the classic ESB pattern to consider. Tailor your own suit. Are you more of a classic or a distributed fit?
5. Can API gateway help you break your monolith?
It’s a very common feeling that when you see this large applications/systems/bricks/rocks/woods monolith, at first you don’t know what to do. You may want to rewrite it, split it, extract services or try to strangle it. Or just look away and marry it if you truly have a lack of faith.
One of the ways we often choose is to try to strangle the beast. Partly because we like Martin Fowler a lot (check here: https://www.martinfowler.com/bliki/StranglerApplication.html), but also because it is a nice and very pragmatic way to do it. API gateway as a concept can be of great help here. You can position your logical API gateways in the right spots within your enterprise architecture, allowing for enough flexibility and governance to safely start strangling the monolith. And then slowly move its parts to your new cloud native environment.
Just call us, we’ll be happy to share the experience. Or come to see Sam Newman on our next QED conference (May 2019!) in Mali Lošinj. We’ll cook some cloud native sauce together there. Of course, our friends from Container Solutions will also be there.
NOTE: If you liked this summary, don’t thank me. Thank our authors for sharing their thoughts.