Why Build StepZen as a Service?
Software is magical. However, software doesn’t run in the ether (maybe because there is no ether - well, other than a pleasant-smelling colorless volatile liquid, not at all useful for running software :). Software needs real hardware to run on.
Early on at StepZen, we had a decision to make. Shall we build container deployed software that a developer could deploy on her infrastructure (or serverless), or do we provide StepZen-as-a-Service?
We decided on a SaaS model. That is why we say:
Get the Data You Want. Using APIs Built Through Configuration. And Manage Zero Infrastructure.
The reasons for this choice are simple.
Our goal is to take away the friction between what the frontend developers want and what the backend data sources expose. Deploying infrastructure is a major friction that we would reintroduce if we were to follow a pure software model.
One of the reasons for the growth of APIs has been APIs-as-a-business-model. Stripe is a payments API. Twilio is a communications API. These are available as a service, which means the frontend developer doesn’t have to worry about payment or communications going down. Why should she now have to run the APIs that connect all of these together?
Getting things like retries, caching, protocol mediations, continuous improvements, auto-scaling, IP whitelisting, and so on right is extremely difficult to do as pure software.
Finally, our ability to innovate is much much higher in a SaaS model.
That said, our software is built on Kubernetes, so we can well imagine that we’d be available for on-premesis container deployments in the future. However, for now, just configure, and get an endpoint that is always on. That’s StepZen for you.