Posted on

Using the Strangler Pattern to Break Down Your E-Commerce Monolith

Introduction

Monolithic platforms like Shopify, Oracle ATG, and BigCommerce are easy to get up and running. However, they lock you into various platform-specific limitations. As a result, you're subject to each platform’s constraints and may feel stuck using one-size-fits-all software.

You face similar challenges if you’ve built your own e-commerce monolith. When more components of the application are intertwined, it is harder to modify features, scale components, or divide the work. After years of using one of these systems, technical debt builds up, and changes are hard to implement.

Posted on

Monolith Modernization With APIs: What Is the Strangler Pattern?

the strangler pattern

Any organization that is not starting from scratch has existing IT systems and infrastructure in place. In many cases, this legacy has issues keeping up with today's demand for how quickly organizations need to be able to adapt and change. One common pattern in larger organizations is "monolithic applications" which often have been around for quite a while and are highly integrated and complex IT systems.

Since these monolithic systems tend to be calcified to a certain extent, they often reflect (and have been painstakingly optimized) the way an organization works currently, but they often also are hard to change when the organization wants or needs to make changes to what it does and how it does it. Microservices often are mentioned as a way to avoid some disadvantages of monolithic approaches, but since many organizations already have monolithic applications around, how can you transition from the old to the new?

Posted on

Know the Business Case for Rearchitecting

Today, it’s pretty normal to write new applications in a “cloud-native” way. Whether we deliver to a public cloud or use a container fabric behind the firewall, we commonly work with microservices or serverless. A data store is as likely to be block storage or Mongo as it is a traditional database. This makes sense. Small components match well with DevOps teams operating independently (see Conway). In general, modern architecture, infrastructure, and delivery approaches support more frequent releases and more resiliency in production. All good things.

However, most apps are not new. A typical enterprise can have many hundreds to a couple of thousand existing applications. Do they sit as they are until replaced? Do we rearchitect them all? Will some move? And if so, which?