As a consultant for Red Hat, I have the privilege of seeing many customers. Some of them are working to find ways to split their applications in smaller chunks to implement the microservices architecture. I’m sure this trend is generalized even outside my own group of the customers.
There is undoubtedly hype around microservices. Some organizations are moving toward microservices because it’s a trend, rather than to achieve a clear and measurable objective.
In the process, these organizations are missing a few key points, and when we all awake from this microservices “hype”, some of these organizations will discover that they now have to take care of ten projects when before they had one, without any tangible gain.
To understand what it takes to reap real benefits from microservices, let’s look at how this neologism came to being.
Continue reading “An Incremental Path to Microservices”
Several organizations are wondering (and sometimes struggling on) how to port their current workloads to cloud environments.
Continue reading “Architectural Cross-Cutting Concerns of Cloud Native Applications”
Editor’s note: Raffaele Spazzoli is an Architect with Red Hat Consulting’s PaaS and DevOps Practice. This blog post reflects his experience working for Key Bank prior to joining Red Hat.
A recount of the journey from three-months, to one-week release cycle-time.
This is the journey of KeyBank, a super-regional bank, from quarterly deployments to production to weekly deployments to production. In the process we adopted all open source software migrating from WebSphere to Tomcat and adopting OpenShift as our private Linux container cloud platform. We did this in the context of the digital channel modernization project, arguably the most important project for the bank during that period of time.
The scope of the digital channel modernization project was to migrate a 15-year old Java web app that was servlet-based, developed on a homegrown MVC framework and running on Java 1.6 and WebSphere 7.x to a more modern web experience and to create a new mobile web app.
This web app had grown more expensive to maintain and to meet our SLAs. It was the quintessential monolith app. Our architectural objective was to create an API layer to separate the presentation logic (web or mobile) from the business logic — what lay ahead was an effort to completely modernize the continuous integration and deployment process.
Continue reading “The fast-moving monolith: how we sped-up delivery from every three months, to every week”