Monolith. The ominous name signifies something big, unmovable, and difficult to deal with.

And that’s exactly what a monolithic application is. At least in the long run.

How to recognize monoliths

How do you recognize a monolithic application?

You probably recognize it subconsciously in the way you feel about an application when it’s brought up. It’s that application you internally cringe towards when someone mentions rolling out the next version. Perhaps it’s been around since the end of the third age (~6,000 years ago for you non-LOTR fans), nobody has dared touch it in 10 years, yet it’s performing a critical business function.

Or worse, you must do a significant amount of regression testing across the application, the testing cycle takes forever, and you can always count on a few production bugs infesting the build rolled out.

All these scenarios can indicate you have a monolithic application. Yuck. Now what?

You’re stuck in that endless consideration to blow it up and start over somehow, spend a lot per tweak, or live with its current state, none of which are enjoyable processes for you to consider. At some point, the application becomes a legacy application you no longer upgrade, limiting your users to the feature set it contains, or spend a lot more than you want to keep evolving it for them. Unpleasant options all.

In a nutshell, the same characteristics that make a mountain so intimidating are the same reasons a big, monolithic application is painful.

How’d we get here?

Let’s time warp back to CS101 – Principles of Software Engineering with Dr. Brown-Jacket-With-Patches at State U. They taught you that tightly coupled designs were not as good as loosely coupled designs. What happened? You traded loosely coupled design and its long-term benefits for some short term business value.

Maybe you needed that app TOMORROW. Maybe you had staff with limited experience. Maybe you rushed it through production. Or maybe it was death by a thousand paper cuts over time – enhancement by enhancement.

“This is just for a few months” turned into business critical and it is still around, years later. Maybe the system designer wasn’t the best choice for the job. Whoops! Should have hired that consultant. It’s ok, we’ve all been there.

This all sounds familiar

Regardless of the ‘how’, you’ve ended up with a ginormous mass of tightly-coupled components over time.

Years ago, loosely coupled designs were accomplished by building more modular, reusable components – like functions or classes in object-oriented programming languages and platforms in the late 90s.

Maybe you encapsulated some business logic in a COM component referenced by ASP pages.

Then, things gravitated to more segmented, decoupled components like XML web services wrapping reusable logic called from frameworks that focused on messaging or user interfaces.

We all did the best we could with the tools we had.

A modern approach – a true advantage

Today, we have modern cloud platforms that allow more decoupling than ever – web API endpoints, AWS Lambda, Azure Functions – we even have serverless systems.

These modern platforms enable your business to have greater agility, flexibility, and speed – the real value of the cloud.

Now, if you want to fix a bug, you can fix a microservice that can be tested at the building block level. You can pull that component out and plug a new one in, much like swapping a hard disk in your disk array. And with modern DevOps and testing tools, that single component can be tested independently and replaced with much less impact and risk to the overall systems.

That’s the power of a well-architected, decoupled system – the antithesis of a giant mass of spaghetti code.

So, how can you migrate away from monolithic applications? How can you leverage the cloud and well-architected principles to achieve speed and flexibility? How can you increase the speed of delivery and improve quality? Are you ready to slay that monolithic dragon?

Contact us to learn more – we’re happy to discuss and design a path away from the dreaded monolith.

Nathan Hiscock is the Client Innovation Director at CleanSlate. He has an extensive background in helping clients fix their problems with innovative value driven technology solutions and collaborative vendor partnerships. Nathan is heavily involved with community engagements and strives to help others overcome adversities. CleanSlate is very fortunate to have Nathan on our team and for the great work that he provides.

Molly Hyslop

Enterprise Sales Executive

Molly is an experienced business development and sales executive with extensive experience in cloud consulting for AWS and Azure. She makes a positive impact in every interaction she has with her clients and CleanSlate’s partners. Molly’s positive spirit drives her to view situations with the “glass half full” and her competitiveness aids in her success on the sales team. Outside of work, Molly relaxes by going on walks, reading, and watching her favorite Netflix and Hulu shows.

Q: Can you give a brief background on your career history?
A: I started out my career with Hewlett Packard Enterprise at one of their call centers, as an Inside Sales representative. During my time there I was fortunate to experience many new opportunities supporting different regions, interacting with different business units and leadership while selling different products. From there my career evolved into sales enablement and business development. The last 5 years have been focused on business development; cultivating new relationships for business opportunities. Now at CSTG, I have the opportunity to not only cultivate but maintain those same relationships and continue to support my clients. I enjoy getting to support clients throughout the entire “sales cycle”.

Q: What does your day-to-day look like at CleanSlate?
A: My day general consists of the following: meetings with clients, meetings with new potential clients and reaching out to schedule meetings with potential new clients for CSTG, with a lot of follow-up with partners and clients in between.

Q: What do you like about working at CleanSlate?
A: I enjoy working with my team, they are great people and hard workers. Who doesn’t appreciate that?

Q: What gets you excited about your everyday work?
A: A new challenge everyday- there is also the opportunity to learn something new.

Q: What are you looking forward to at CleanSlate and in your career?
A: Looking forward to building more client relationships and bringing them value.

Q: What are some non work-related activities that you do in your day-to-day? (this probably looks a little bit different than it did pre-covid)?
A: I enjoy/need some type of physical activity; usually walks in the neighborhood during lunch or for an afternoon break. After work, I enjoy reading books and relaxing watching my favorite Netflix/Hulu shows.

Q: What are one or two long-term goals you have?
A: Goal is to continue to create awareness of who CSTG is, so far, I feel like I have been successful, but we all know sales is never over and your consistently starting over so that goal will continue.

You see the term microservices tossed around often on powerpoint slides, webinars, and sales glossy handouts, but it’s one of those words that we seldom discuss in detail as developers. Let’s cut through the noise and talk about what this means to you, a developer.

Why Microservices

AWS themselves have a few things to say about this, and we’ll touch on each of them shortly.

• Pick the Right Tool for the Job
• Improved Resiliency
• Refined Cost control
• Improved Team productivity
• Reuse with Composition
• Safely experiment, Reduce Failure Impact
• Accelerate Tech Adoption
• Deploy Faster, and Safer

Pick the Right Tool for the Job

One misunderstanding about this is that it’s just a buffet of programming languages and stacks that you get to pick whatever you want to use. It promises freedom from bureaucracy telling you what to use.

Is it maybe a little bit of that? Sure. But that’s not really the intent. It’s a lot less about language choice, and a lot more about systems design.

Netflix, for example, uses a concept they call the “Paved Road.” There are a core set of languages, stacks, libraries, and services that are very well understood. And most importantly, very well supported internally. There is flexibility, but it’s the most-supported “road” to stay close to.

Can you wander off-road? Sure, but you’re a little bit on your own at that point, and need to make that decision intentionally, and do extra things to mitigate risks.

So what is an example of “the right tool” not being about programming languages? Data stores. Specifically, picking the correct, purpose-built data store for the service.

If the service is going to be highly transactional, with purely relational data, Redis is not going to be the best choice. If the service requires burstable high-throughput writes of non relational data, DynamoDB may be a better fit than a large RDS instance.

To sum it up:

• It’s not 30 programming languages
• Stick to Paved Road (Netflix example)
• Purpose-built data stores (recommended practice)

Improved Resiliency

Resiliency is crucial when architecting systems. Failure should be expected as a rule, not treated as an exception. There are things beyond control, but not beyond design. Identify failure modes, and compensate for those from the beginning.

Microservices allow you to take the many different parts of your system and separate them into controllable pieces that all have their own failure modes. What happens when one service fails? The entire system need not come crumbling down. Instead, it may just result in temporary availability issues of one part of the system. How about an example?

Take a look at the entirety of Amazon eCommerce. To start, you can break this into a few crucial components:

• Inventory Listing (How do we see the thing?)
• Adding things to carts (How do we select the thing?)
• Financial transactions (How do we buy thing?)
• Logistics and Delivery (How do we get the thing?)

Taking a look at financial transactions. One could say for an eCommerce company, and outage of this functionality would be the end of the world, and we’d call the whole thing “crashed”. With a monolith, you’d be right.

However, just because you can’t pay for a thing doesn’t mean things currently on trucks just… stop being on trucks on the way to you. Nor does it mean you just can’t list any items. And it also doesn’t mean you can’t still shop and select items you want to buy. You know, when the payment service recovers.

To sum it up:

• One service failing should not be a total system failure
• Inventory, add to cart, payment, shipping, should be independent and fault tolerant

Refined Cost Control

In a monolith, the environment must scale up to the demand that is required by any part of the system. WordPress is a great example of this. Regardless what part of the CMS is experiencing the demand, the entire thing must grow to compensate for this.

However, if this were broken apart into independent services, those could be scaled independently, leaving the other services right where they were. And metrics can be granularly collected on each service to pinpoint exactly which one is experiencing demand increase.

If the internet is giving your latest article a great big hug, you shouldn’t need to scale the authoring service if you’re the only one authoring content.

To sum it up:

• Each service can be measured independently
• Each service can scale independently
• Each service can have it’s own approved quotas and alerting

Improved Team Productivity

Developing features and remediating defects in a monolith requires a wholesale reproduction of the entire system and stack, just to get started. Depending on the size and complexity of such a monolith, even the most sophisticated development environments can be sufficiently taxed for resources.

There’s also the “where is the problem” aspect of tracking down the issue, finding the code culprits, then fixing (hopefully) the problem. The entire stack then needs shoved through the CI/CD pipeline, and redeployed in its entirety, often involving some system-wide downtime.

Alternatively, with microservices, it’s easier to track down an individual service’s failure (thanks to more fine grained alerting, logging, and monitoring). This then means there is less complexity to reproduce, and find, and fix, and push, and redeploy.

As discussed above, it’s possible for this entire process to be done with minimal interruption to the system if we’ve architected for expected failure modes.

To sum it up:

• Far easier to collaborate via api contracts
• Faster and easier to unit test and develop against specific services
• Faster to run a service vs an entire stack
• Mocking stacks to api contracts

Reuse with Composition

If we think about the Single Responsibility Principle in software design, and apply the same line of thought to systems and services, a fascinating pattern emerges. So long as we honor our existing service contracts, we can enhance our service as feature requirements change, with impact limited to only the responsible service.

Additionally, it often happens that a service already exists that can just be leveraged by another system as business needs change. As an example, a service that aggregates metrics and analytics data could then be orchestrated into a new service to collect user behavior data, uptime reporting, resource utilization, and much more.

The additional use cases require changes only to one service, instead of something that threads and snakes its way through the monolith. Or worse, complete rewrites of previously-working functionality.

To sum it up:

• New use cases don’t require rewrites
• Services can consume others as new features are made available

Safely Experiment, Reduce Failure Impact

Experimenting with new technology and design patterns used to be quite difficult in a monolith. One particular challenge is the codebase itself; keeping in sync with the rest of the changes while you develop your experiment. Using a service based architecture reduces the amount of “other” code you are competing with as you try to migrate to a new pattern.

As an example, trying to migrate to leveraging state machines for state management. It’s difficult to do this to an entire monolithic application, but can be more manageable when limited to a purpose-built, focused service, while not impacting others.

To sum it up:

• Experiment in controlled isolation
• Easily deprecate failed experiments
• One bad feature doesn’t bring down an existing system

Accelerate Tech Adoption

As an example, adopting new logging and metrics tools is scoped down to a single, focused service. And if the experiment is deemed a failure, the impact of that failure is restricted down to just the service, while the rest of the system can still perform as before. Consider it a canary, of sorts.

And any time a new service is being considered, it’s a perfect opportunity to use it as a test bed for a new emerging technology or a different design pattern. The risk is tightly controlled, and more easily measured and evaluated.

Additionally because there is less functionality and responsibility in a single microservice, there is also much less to grok for new team members when trying to onboard. These new contributors can more quickly bring their expertise and new ideas to the project, demonstrate the ideas, and perhaps kick off a broader adoption in other services in a planned and coordinated fashion.

To sum it up:

• Allows adopting new tech in isolation vs entire stack rewrite
• Allows new team members to bring new experience to the team and freedom to more narrowly demonstrate future tech

Deploy Faster, and Safer

Ah, deploy day. Or night. What a time to be alive, right? Middle of the night, sure hope traffic is low and everyone is logged out. Hope it all goes as planned. Oh it didn’t? Hecc, how do we unravel this, redeploy the whole thing another time after we fixed this.

That’s life in the monolith. Personally? I don’t miss it.

Instead, it’s less stress when focusing on a single service. Consider possibly a canary or a blue-green deployment. The code changes are smaller, the build and test times are faster, the deploy and go-live times are minutes, not hours.

Problem with the deploy? You still need to roll back, but the rest of the system is left much less disturbed, and the previous working version will be reverted to via DNS or redeployed much faster than an entire monolith.

To sum it up:

• Deploying the world vs one service
• Downtime is shorter or non-existent
• Rollbacks are faster

Recap

Breaking a monolith into loosely-coupled, event-driven services offers some amazing potential benefits in the areas of cost, flexibility, and security.

This is not to say there won’t be challenges. Microservices done poorly are worse than a mediocre monolith. The complications will normally come in a few flavors:

• Service discover
• Versioning
• Couple-changes
• Breaking contracts

With this in mind, make sure to have a discussion with your team. Identify those challenge points and consider them from the start as you start to adopt an application modernization effort, or green field development.

David is the AWS Technical Architect at CleanSlate Technology Group. Coming from over a decade of custom application development, deep expertise in CI/CD and cloud operations, he brings a breadth and depth of experience to all teams to advise, direct, and implement solutions that surprise and delight our clients. With a focus on developer experience, collaboration, and state-of-the-art architecture and strategy, David works closely with our partners, vendors, clients and staff to ensure CleanSlate Technology Group advises and implements the best of breed solutions with a focus on quality, resiliency, cost management, security, and privacy.

Source: Red Hat

Dave is the Director of Marketing for CleanSlate Technology Group. An experienced marketing & technology professional with expertise in developing and executing strategic marketing programs, building exceptional teams, and driving ROI. His past results include 705% return on ad spend, 90% increase in lead generation, $1.2M gross sales in 9 months, 67% boost in organic search traffic and a 448% rise in online testimonials. He has led a team of 10 and controlled a $6.1MM budget. (Source: LinkedIn)