AWS and MSFT do not like to coexist

by

We have a tool for data testing purposes during a data migration project in the context of Insurance.

This tool started to be build in MS- Power-BI. It progressed well, use case validated, and suddenly we had to expand it.

Once that was done and it was working well with high volume: over 500k policies. We asked ourselves, where do we want to move next?

The answer was, we need:

  • Better time response,
  • Ability to deploy automatically
  • Start offering AI features.

In the context where we work, AWS is the preferred partner for building solutions, and to swim against the current is an error.

We have a mandate where we had to enable the deployment un Deployment Units, and this should be working in AWS environments with a set of security layers.

In addition to that some client requirements came with: “you need to deploy your fantastic tool in AWS”.

So, ok, we have to move things to AWS. We started with a question,:

how we better connect both worlds (AWS and Microsoft)?

After some frustration to find the answer and trying to find and answer and a solution for the structure of the new version of the tool, we found out that it was the wrong question. A better way to see the situation was:

How can we get advantage using the pros of both words (AWS and MSFT) and limiting their constraints?

Since we change the perspective, we did 2 things. Here the merit should be on the developer, he is the one that made it real.

First, we explored how to build the tools where the backend is in AWS (and the operations are handled with web UI based in our standard) and the front end (for the end users (mainly Business Analysts) ) are in Microsoft world.

Second, build it in 2 steps: first the database moved to AWS, then the rest.

The interesting tweak here, was the constraint obliged us to have automated Deployment Units is in part what forced us to separate the tool in that way. This was the trigger that helped made us move; then the future needs on the AI features helped too.

This also helped us to understand something we are exploring for other tools. An oversimplified reading of the competitive landscape we compete:

  • Our moat is the ability to handle complex data models, and the business knowledge.
  • Our users are mainly Business Analysts. (we could pretend that we offer services for tech people, but let’s be honest the big players are able to deliver at fastest speed than us; in the buy/build decision we should by tools for developers and promote adoption that combined with knowledge provide superior value).
  • AWS offers good back-end services, poor front end; the cost/time of building Front-end is high.
  • Microsoft: offers great front-end. Our Platform is mainly deployed on AWS Infrastructure; and implementing things on MS-Asure is to go against the flow of the entire organization.

So, with this tool we found out a way to take the best of the two worlds. Would this type of solution could fit for other tools we are building? time will tell us….

Leave a Comment