As software developers, we are often responsible for making challenging technical decisions. At the highest levels, this means narrowing down the vast selection of software choices and architecture styles available and figuring out which work best together that drive sustainability, scalability, reusability, and rapid development cycles.

What framework should I use? What is the best way to handle DevOps? What third party libraries should I incorporate in my stack?

These are just a few of the decisions that need to be constantly evaluated in software development, and the success of these choices is often what separates the good from the great.

One of the questions we often get asked is, “How should we handle integrations?” Enter Microservices.

Before discussing why Microservices can be so powerful for dealing with integrations, let’s start with what a Microservice is.

A Microservice is most broadly defined as a single process that deals with a small set of functional elements that is architecturally separate from other functional services.

This is an opposing architectural design to the “monolithic application,” where every element of functionality is built into one process and service (Martin Fowler). There are many who like to argue in favor of one style vs. the other, but I’m not interested (nor capable!) in doing so, and the truth is that it probably depends, and should be treated as another technical decision to add to the list above. However, I will argue that Microservices are a perfect fit for handling integrations with OrderCloud.

Let’s discuss why.

OrderCloud is a “Best-Of-Breed” software that has most everything you need for the complex relational and order requirements for B2B commerce. And while “Best-Of-Breed” is a shorthand way to describe software that is incredibly effective at fulfilling a set of specific requirements, it also implies that there are other features that are not inherently supported. How do you handle payment processing? Calculating shipping costs? Tax? Content Management? Shipping? ERP? Email Confirmations? These are all very complex problems with unique requirements and can all be handled by integrating with other “Best-Of-Breed” software providers.

So how do you build these integrations? There are three general options:

  1. The first thought you may have is, “how can I build these integrations into my existing tech stack?” Let’s say for example you already have a core service built in .NET. In this scenario, you would extend this service to deal with your integrations and then expose them through an API so your eCommerce application can communicate with them. But this can be an extremely daunting task. Are the integration libraries compatible with your current stack? Do you understand the security ramifications of publicly exposing these integrations through an API in the same service that your company’s core technology is being run in? Can you rapidly build and deploy these integrations, or do you have to go through hoops to make that happen? Could these integrations increase the load on our servers and potentially bring down the whole thing? You can probably imagine the amount of work to make it possible, let alone making it fast and efficient.
  2. The second option is to go through an integration service provider. These services tend to support many integrations and give you a GUI to create and visualize each step if an integration workflow. One of the challenges we have found is that there tends to be a learning curve when it comes to figuring out how to use them in an impactful way, which can add to the costs due to necessary training. Another is that it adds yet another piece of the puzzle that you don’t have full control over, due to them being hosted services. However, if you have the budget for these services and you are okay with the concerns above, I recommend considering this option.
  3. The final option is to build a Microservice. With a Microservice, you have full control over the software choices, meaning you can pick what works best for your needs. Additionally, the team working on the integrations doesn’t have nearly as much to worry about for security (although still important), because the service itself only concerns itself with integrations and is not sitting next to your core services that may directly access your company’s databases. And probably the most important reason of why a Microservice is a great choice is speed. The fact that the microservice is architecturally independent from any of your existing software means your team can rapidly develop and deploy your integrations without having to deal with the standard release cycles during the buildout phase. One concern I often hear about choosing a Microservice is, “What do I do if I need to connect to my core services?” Even this can be easy and secure given the right technical decisions. All you need to do is expose a private API on your network that your Microservice can access, and only make the Microservice publicly exposed.

Making the decision on how to deal with Integrations is a difficult choice. The decision is yours to make, but what we’ve found is you will experience more rapid development, control, and ease if you choose to do so with a Microservice. 

Comments

comments