The first challenge most enterprises face on their Journey to Cloud Native architectural transformation is the Monolith. As the name implies, these large applications can be difficult to envision in a Cloud Native environment. This week we share some tips on how to approach it, tangible steps you can take, and some salient lessons from history.
PLAY EPISODE
SHOW NOTES
- Subscribe to the feed
- Feedback: podcast@pivotal.io
- Links referred to in the show:
TRANSCRIPT
Announcer:
Welcome to the Pivotal Perspectives Podcast, the podcast of the intersection of Agile, Cloud, and Big Data. Stay tuned for regular updates, technical deep dives, architecture discussions, and interviews. Now let’s join Pivotal’s Australia and New Zealand’s CTO, Simon Elisha, for the Pivotal Perspectives Podcast.
Simon Elisha:
Hello, everyone. Welcome back. Thanks for joining me again for another week of the Pivotal Perspective’s Podcast. This week I thought we would speak a little bit about monoliths. In terms of software and digital transformation and change in IT, the term “monolith” is coming up as often as the term “microservices.” Monolith is often used in a pejorative sense to talk about an existing typically large application that by merit of its architecture and deployment model makes it hard for it to move into the new world of cloud applications and certainly does not qualify as what we would call a Cloud Native app.
It doesn’t necessarily exhibit the qualities of scalability, of elasticity, of robustness and resilience. It doesn’t scale on an economic basis, it’s typically supported by very specific infrastructure rather than some sort of more generic IaaS or portable layer. It’s typically hard to make change because the code base is large. Which typically also means that roll outs are less frequent, which means that you end up with unhappy customers because they don’t get a more modern experience.
Now, obviously talking to customers as I do about things like Cloud Native platforms and modern development techniques, etc. it’s all well and good to focus on the new and shiny. I’ve got a new application so I’m going to adopt my Cloud Native approaches. It’s going to be a 12 factor app, there’s going to be microservices. It will be deployed on Pivotal Cloud Foundry. It will be scalable and resilient, my world will be wonderful. I’ll be using full agile. I’ll be deploying using continuous integration and continuous deployment, so my production changes are fantastic and I’m doing blue green deployment. Life is great.
Whenever you talk to experienced IT people they will typically focus on the monolith in their backyard. Many of them will have a pet hate application that’s existing in their world, or they’ll just know that there are some big ugly secrets there that have to be dealt with. So I thought I’d go through a few approaches and some concepts that are worth bearing in mind when you’re tackling this kind of problem.
The first thing I would say is don’t let the challenge of doing something prevent you from doing anything. This can be termed “analysis paralysis,” or “over engineering,” or “procrastination for the sake of procrastination.” Do something. That something doesn’t mean you have to come up with the all singing all dancing strategy to cope with your 6,000 applications in one fell swoop. Choose 2. Start with 1. Learn something. Test something out. Give it a go. There’s a saying that the way to eat an elephant is one bite at a time.
I’m, firstly, not advocating consuming elephants, but it’s true. Getting overwhelmed by your legacy infrastructure, your existing estate, is often the biggest problem. There’s so many, “But we can’t because of this system or that system, etc.” It’s amazing when you start turning that thought process around, this is a cultural thing, to, “We can, and this is how we will do it. Or we’ll try and see if it works.”
What are some of the practical approaches? There’s a number of patents that are emerging and things that are being published and I’ll share some links in the show notes to that. Really, they all have the same view which is to take this monolith and to slice it up. Slice it up in some dimension. It could be functional dimensions, it could be existing architecture relationships within the application. It could be components that are easily replaceable by commercial components. As I mention, a variety of approaches. There’s some really good tips you’ll get from a book by Matt Stine and also a series on the Pivotal blog put together by Jared Gordon, just to name a couple of how to do these different things.
I wanted to let you know a little secret here, and it’s a secret I haven’t heard spoken too much about in circles, so you heard it here first. The secret is that in general, monoliths are not monolithic. They look monolithic if you look at it from an infrastructure perspective. But from a code perspective, unless the code is monumentally bad, and that can happen, they are typically not monolithic.
The reason why they get called monoliths or people view them as a monolith is because of their deployable unit. “I need a honking great server to put this big application on because it consumes X amount of RAM and needs so much CPU and that’s the only way it will scale, captain.” From an infrastructure view, say, “Ah ha! I have a monolith. It needs a honking great server.” But if you take off your infrastructure hat and put on your software engineering hat and actually dive into the code, you’ll see a wonderful world of relationships and subsystems and functional areas of responsibility, and discreetly separate data structures or federated components. Components that could easily be re factored or redeployed as separate components, rather than coupled through namespace or the code environment that they happen to live in. In fact, many monoliths are monolithic only because that’s how it was easy to develop them. Not because they were done by design or necessarily have to be that way.
When you’re decoupling or de-monolithifying … How’s that for a new verb? You need to get away from some lazy practices. We’re all lazy in our world. In fact, I often say that a good programmer is a lazy programmer, because they should be doing the least possible amount of work to get the job done effectively. There are some lazy practices that I’ll use in the pejorative sense that stop us from becoming Cloud native or more flexible in our approach to deploy. Probably the number 1 that I see out there is use as a single database as a form of information exchange. It is a terrible pattern repeated many many times. I’m sure I was guilty of it myself in the past. It contributes to this morass of dependencies that create an unchangeable mull of mud monolith.
So you need to stop doing that. One way of doing that is when you’re building, for example, new micro services. The service data storage or storage of state is encapsulated within the service itself and is not exposed or used to be shared by anything else. If you want to share data with that service you can do so via it’s API built for that purpose.
Other things you need to do: you can’t assume that you’re in the same namespace for everything. Distributed systems are distributed. But then if they’re distributed you also need to consider things like network latencies, time outs, and other things. This is why a really cool things like Spring Cloud Services can make life a lot easier in terms of coping with some of the challenges of distributed systems. You need to learn about distributed systems. But again, all this stuff is how we learn and how we change.
I wanted to talk about some of the lazy practices of the past, because as I said, none of this is new. I’ve been doing this for over 25 years now, and I’ve seen a thing or 2. So I’m going to ask your forgiveness if I tell an old man’s story for a moment. This qualifies as an, “In my day …”
In my day, when I started off in development, I was working in COBOL, and COBOL had the concept of stamp data coupling, often shortened to stamp data. I’m sure most of the listenership is going, “What the hell is stamp data?” Maybe 1 or 2 of you is going, “Ah ha! I remember that.” Stamp data was the concept of sending data between subroutines or subprograms that weren’t actually needed by that particular program. You’d send this entire data structure to the subprogram, and it may only need 2 fields of that data structure, but you sent the whole thing along.
The kind of apocryphal story of why it’s called stamp data is because in the old days, the data structure was documented in the form of a rubber stamp that you would stamp on your specification, and then you’d write your pseudo-code underneath that. Because the stamp had everything on it, you would just tick the items that would actually be used, although you’d move all the data. It was typically implemented in the form of COBOL copybooks, and god, there’s a great technology for you there. But it was a great example of a well-accepted practice that made sense from an efficiency perspective, but created this lazy practice of sending data around that actually wasn’t needed by sub components, but could be affected by sub components because it was being passed around.
What’s my point, besides telling an old man yells at cloud story? There are bad habits that we have, we move away from them, we learn from them, we change from them. There are many of those that will be encapsulated in the code that you have.
So, how do you tackle this monolith? How do you get into it? How do you do something? I’m saying don’t sit there an plan for 6 months, do something. Here’s an absolute ripper of a shortcut: set up a small team who is interested in doing this, who can take a monolith. Choose the one you want, you can choose the easiest one, you can choose the hardest one, you can choose one in the middle, you can choose the one you have the most knowledge of, the one you have language skills in, your choice. Pick one and re-host it somewhere that is Cloud Native. Pivotal Web Services, Pivotal Cloud Foundry, whatever. Just get it up and running in monolith form as best you can. Again, Jared Gordon’s series is great about this.
Once you’ve got it up and running, then you have that team attack it. They start to dive into the code. Remember, don’t look at it as a big infrastructure based application, look at it as a code base. See how you can break it up. See where the natural lines of division lie. See where you can take a particular service and re-implement it in some other way, and then have some sort of proxy layer. See if there are slices of function out there that you can remove. You’ll often see, again back to lazy programming, entire components of the system that are federated only by their presence in the common database. That’s all. The structures actually don’t talk to one another.
You have this team getting there, have them work in an agile, dynamic way. Test driven development, peer programming highly recommended, and it’s amazing what can be done in just 2 or 3 sprints. 2 or 3 weeks working away at this code, they’ll get a very good idea of how applicable breaking the monolith up will be in your environment for this particular application. They’ll also learn a lot of techniques about how to break up a monolith as well.
The other informed choice I would recommend is that if you’re looking at a particular system and you say, “Well, I have this code running. It’s been running for a long time. I have no idea about exactly how it’s implemented.” That’s a good cue to look at re-platforming. Now, if it’s not a differentiating function, so it’s something that’s pretty standard, then pretty much you should be looking at software as a service. How can you consume this as a service from somewhere else? Because it’s not differentiating. If it is differentiating, so it’s making your business different, it’s inspiring a different interaction from your customers or your employees with how your business operates, then you should be paying close attention to it, investing in it, modernizing it, and looking to capture what it does and implementing it in a far more modern and cost effective way to maintain.
Often, monoliths live in old infrastructure that cost a lot of money to maintain, to license. Particularly things like application services, etc., tend to consume a lot of licensing. Or if you’re using some of the old database technologies, they can often have a significant maintenance cost as well. It’s amazing how much money you can save by re-platforming and using open source technologies, and using modern technologies as well.
So that’s a little bit of a discussion about monoliths and how you may tackle them. Give it some thought. Again, don’t let the challenge of doing something prevent you from doing anything. Until next time, keep on building.
Announcer:
Thanks for listening to the Pivotal Perspectives Podcast with Simon Elisha. We trust you’ve enjoyed it, and ask that you share it with other people who may also be interested. Now we’d love to hear your feedback, so please send any comment or suggestions to podcast@pivotal.io.
We look forward to having you join us next time on the Pivotal Perspectives Podcast.
About the Author
