A decade ago, when everyone was still wrapping their heads around the idea of cloud computing, one ongoing point of concern was the fear of vendor lock-in. The idea was that if you relied on a single company to provide all of your cloud services from top to bottom, you would be locked in and lack the flexibility to try new services from other vendors until your contract expired — even if another company offered a better product. If you wanted to add other services, you’d be on the hook for substantial expenses to migrate.

Eventually, the tech industry listened and learned that customers don’t want a one-size-fits-all approach; they want the ability to pick and choose different pieces and services depending on their specific needs. Unfortunately, some e-commerce platform vendors didn’t get the memo because they’re still operating as monoliths.

While some e-commerce platforms have learned the value of flexibility, for others, the pendulum has swung in the opposite direction in favor of microservices, an architecture composed of loosely coupled services connected through APIs to create a complete system. Think of microservices like Lego blocks without an instruction manual to piece them together to build that creation you had perfectly envisioned.

A microservices approach can be tempting for online retailers for several reasons. First, commerce is becoming increasingly focused on content and customer experience. By decoupling the front end (the part customers interact with) from the back end (the part that enables transactions and powers the store), developers can customize and manage the two sides separately.

Second, merchants can have multiple front-end experiences connected to one back end, creating opportunities to implement several new customer-facing touch points (e.g., a blog, a traditional website or even a unique app). Third, developers have more flexibility to adjust code on the back end without affecting the part customers interact with. They also have choices for different services to power the site instead of using only what the monolith vendor offers.

While microservices offer some significant advantages over monoliths, that approach has flaws of its own. If you’re an online retailer, you need to think hard about whether you want a monolith or a pure microservice system. The monoliths lock you in, making it difficult to customize your experience without a team of expert developers and a lot of costs.

Microservices, while providing choice and flexibility, put more responsibility for security and payment card industry (PCI) compliance in your hands, as well as leave you to manage uptime and support. Managing the various microservices requires cross-functional, vertical teams that must work together to maintain the site. It can be extremely difficult — and potentially expensive — to put all of those Lego pieces together in a way that creates a compelling and manageable customer experience.

One emerging way to build an open system that prioritizes the customer experience is headless commerce, which provides a safe, secure platform while also enabling simple, fast integrations with other applications to provide the service merchants need and customers want. For experience-focused brands (e.g., lifestyle products), direct-to-consumer brands and companies that rely heavily on influencers, native advertising or other content, headless commerce has its advantages.

Headless gives retailers the flexibility to mix a content-focused customer experience with a safe and secure commerce back end. Many brands today are using content to create unique, personalized and exciting experiences for customers. With headless, they can take advantage of the flexibility of content platforms like WordPress or Drupal without sacrificing security behind the scenes.

While microservices require various teams to manage the different pieces, headless doesn’t require specialized teams. That said, headless does bring together two separate tools and, therefore, requires owners to manage two tools instead of one. However, everything connects through the core e-commerce platform, making it easier to manage. Headless also provides flexibility for developers by allowing them to work in the system they are familiar with. Still, some businesses might not want to do that even with the benefit of creating a more experience-driven site.

Microservices can also require changes to the infrastructure and tools used to monitor them, and those changes will likely add to the total cost of the system. Headless, on the other hand, has the benefit of providing flexibility with fewer changes to existing infrastructure.

If you’ve been using a monolith, it might be intimidating to consider a full replatform, but another benefit of switching to headless is that it can be done incrementally. It doesn’t require big, instant change that would disrupt operations. You can decide which capabilities you want to decouple first, and then transition over time while building out other parts.

The biggest challenge to making the switch to headless is that it requires a shift from a product-first mindset to a content-first mindset. That can be tough for many merchants. In addition to managing inventory, production and all the pieces needed to get those products to customers, headless requires time to develop dynamic content and a commitment to keeping things fresh so it feels current for the audience.

Twenty years ago, monoliths or fully custom builds were the only options for e-commerce and other technology systems, but market demand for choice, flexibility and innovation has taken hold. For e-commerce brands, an open API-driven approach is a powerful way to provide positive customer experiences and distinguish themselves from the competition. And in today’s highly competitive online retail environment, everyone could use more ways to set themselves apart from the crowd.

The post E-Commerce Monoliths Or Microservices? The Answer May Be In The Middle appeared first on Artificial Intelligence.

Service Oriented Architecture (SOA) was the great hope of organizations decades ago when they sought to advance legacy system integration, reduce and bypass layers, and rapidly access the system of record. At the time, the existing solution was point-to-point integration, creating a brittle “spaghetti” middle layer that was hard to manage. This was replaced by SOA, which was later augmented with ESB. This fixed the spaghetti mess by creating an intermediate set of layers, which added complexity to the integration process.

Unfortunately, most IT departments with legacy systems and SOA still struggle to be as agile as needed in this ever-increasing global and digitized world. 

SOA Solved Many Problems, But Not All

Today, upward of 90% of the world’s enterprise applications are monolithic. When they were created, monolithic design was the best approach available. However, as business needs evolved and the demand for greater agility intensified, developers and IT teams are considering breaking free of these monolithic architectures.

SOAs have become a hindrance, not the solution they once were.

The SOA Integration Challenge

The promise of SOA initiatives was extending the reach of core business functions while reducing the internal expenses and complexity that grew alongside monoliths. SOAs achieved these goals by breaking the core functions of a monolith into web services using protocols such as simple object access protocol (SOAP) and eXtensible markup language (XML).

SOAP was built for universal application communications. Because it’s based on XML, SOAs designed with SOAP could, in theory, be used to create an agnostic integration layer. Rather than struggling to piece together various proprietary systems, these protocols would open monoliths on different operating systems so they could work together.

This agnostic integration layer would let system administrators connect pieces of a monolith to an enterprise service bus (ESB) to achieve an agile, plug-and-play SOA. In some cases, this approach succeeded.

A great deal of “legacy SOA” still provides value. In these cases, the value the SOA provides is the behind-the-scenes server-to-server communication that mostly aids developers. When it comes to serving internal and external customers–and their rapidly changing demands–SOA isn’t always up to the task.

To achieve service integration, the ESB must oversee the messages from start to destination. This communication isn’t as simple as the SOA vendors may have promised. Consider an SOA integration within a core banking application. The message must go from the core application on the mainframe to a branch office server. If the business logic states a message is only relevant for one business day, administrators must decide whether to move it to a queue, log or disregard when the day passes. This is a common scenario for core banking applications in an SOA, but how well does it work?

In this example–and others like it–the ESB must know whether a business day has passed to make the right decision about where to send the message. Therefore, the integration requires an algorithm–meaning that ESB cannot simply rely on a universal rule for sending messages between the monolith and external integration.

When administrators introduce new business logic into the monolith integration, it turns what was supposed to be an agnostic service layer into a new application layer, increasing complexity. Instead of simply integrating the monolith into a new digital service, the enterprise ends up with a larger monolith–one that includes the mainframe and all the new integration stacks.

Despite the promises of SOA, the integration problems result in increased maintenance time, greater complexity of code and software and the continued growth (not elimination) of monolithic applications.

The first rule of effective integration is “smart end-points and dumb pipes.” Building logic and layers into the service layer breaks that rule, increases the overall complexity and adds another legacy application to your portfolio.

Bottom line: Trying to optimize the SOA approach will only result in larger monoliths.

Improving SOAs with Microservices

Using microservice architectures helps realize the original promise of SOAs, delivering the benefits of SOAs while removing many disadvantages.

For decades, CIOs have tried to transition away from monoliths by taking traditional approaches to integration, only to find they’ve doubled down on legacy investments. All these integration stacks end up coupled to legacy systems and only result in more work for the IT team–and a less agile organization.

The integration step of SOA was never intended to include business logic. Trying to force business logic into this approach leads to workarounds and extra effort just to achieve a less-than-ideal result.

The key factor is how to incorporate microservices without adverse effects. Luckily, microservices architecture can be forged from SOAs by introducing these new principles:

•   Context Mapping: When replacing an existing SOA, teams must consider the size and scope of the new microservice and apply proper contextual boundaries. For example, SOAs that typically sought broad integration with digital services should be broken down into smaller domains to simplify operation.
•   Shared-Nothing Architecture: Too many SOA integrations create sprawling dependencies that create complexity in the tech stack. Microservices avoid these cross-service dependencies. For those looking to move to microservices from an existing SOA, it’s important to look at the list of dependencies and work toward standalone functionality.

The post Microservices: The Advantages of SOA Without Its Drawbacks appeared first on Artificial Intelligence.