I (think) I want to build a microservice based iPasS!

So here's some more random ramblings I want to put into my blog.

I am pretty sure that I want to build my own iPasS. Although as usual I could be wrong and remain (somewhat) persuadable.

I am currently looking into the future of integrations at my organisation (Check out my last blog https://code.metcarob.com/node/13 for a bit more background.)

Our platform is old and needs replacing. We currently have to develop integrations inside one single team which slows us down! I want to be able to offer integrations as a service, I want these integrations to use best practices (like loose coupling), be able to interface with both legacy and new systems, and more. My shopping list is long and built based on experiences I have had building SOAP based integrations between various internal and external systems.

In future I don't want integrations to be built by my team either. I want to offer a simple interface to other development teams to enable them to build rapidly and offer them support in this process.

So lets just buy Mulesoft...

According to Gartner it's a great out of the box product. Apparently a single product built from the ground up to solve all integration problems.
But...

  • Mulesoft developers need to be highly skilled (That's a Gartner 'fact' I picked up from one of their reports)
  • Expensive developers
  • Forget about self service - my team will still need to develop integrations centrally - although we could do it much quicker
  • Large price tag

Expensive and can't do everything

I am told Mulesoft is expensive and this gives me a problem. If I replace my current platform with Mulesoft, puseude management to spend the big bucks on a 'proper' solution it's going to be great until the first use case Mulesoft doesn't support. I guess it will be hackable, maybe I can get some Java programmers in to fill it out, or maybe even build mini adapter services at the edges, but that's extra cost on something that's already expensive.

And if I have to develop and maintain the extra pieces how much extra would it cost to go with a hybrid integration model (HIT in Gartner language.) It only has to be cheaper than Mulesoft to be viable! Also once I convince management to fork out the dough for Mulesoft how am I going to look when I explain it can't do x and I am going to have to buy something else to fill the gap?

Mulesoft isn't really suitable for Integration developer self service?

If it needs highly skilled developers it can't be.

Can Mulesoft allow us to continuously evolve?

If we have a docker based Microservices iPass, then individual components will continually be being developed, deployed, improved, obsoleted and thrown out on short independent life cycles. This continual change could result in a very agile iPaas as a whole. If we buy Mulesoft that's that. I get what they give me, in a few years time when the next new thing gets here I won't be able to take advantage. After getting my bosses to spend big money on Mulesoft I will look like an idiot asking for more to do the things Mulesoft isn't able to.

Why not just buy an iPass?

Well, they don't really exist. This is an emerging sector according to Gartner. I have investigated something called Snaplogic which looks good. I think it can solve some of my requirements, mainly self service. It's an emerging sector and has potential. Certainly none are a complete platform and will have to be pieced together.

Why Microservice based - what about Serverless?

I am very excited about Serverless. The LJC meetups I have attended contained many good things. The idea of not having to learn how to run and maintain a Docker cluster is alluring. There are a few problems though:

  • It's not leading edge it's bleeding edge
  • Very high vendor lock in. (AWS stuff looks great but apps I build there can't transfer.)

The question for my organization is do we build? To be honest I don't know what the answer is for my organization. There are many cultural factors not discussed here. The question for me is do I go ahead and make putting one together a personal 'learning' project. My answer is a resounding yes:

  • It will be fun
  • I will learn and gain experience in building Microservices
  • I will get to grips with Docker, docker swarm
  • I will learn about how Databases like MariaDB fair in a Docker environment.
  • I want to play with Cassandra (I have done some datastak course, but nothing like a real project to push my knowledge.)
  • I can write some blog posts. (Note: I didn't say I would write informative useful, good posts, just posts.)
  • Test out ideas I have been having at work and see if they pan out
  • Test out stuff I hear in conferences and online
  • It will be fun (This is not here twice by mistake)

Some random decisions:

Swarm or Kubernetes?

From what I know Kubernetes is far superior to Docker swarm but there is a much steeper learning curve. Swarm is easier to get into and is included in Docker itself. I have been playing with Swarm for a while and I have gotten used to it.

Someone at work said Swarm is dead but I don't believe him after reading this https://www.bretfisher.com/is-swarm-dead-answered-by-a-docker-captain/ so I am sticking with my choice. (It's only a personal project and Swarm is not the main thing I am wanting to learn anyway.)

Published Date