Growth
Scaling
Typically to scale our systems requires simple configuration changes and the presence of some capacity to exploit. It sounds simple and
that's because we expect growth and our approach is scalable by definition.
More streams of data, more endpoints, more requests placed on the system, higher volumes of data, mirroring of capability, regional expansion, these things are meant to be good news, bigger is better, well apart from complexity and cost, we keep these last two low as far as development is concerned.
Change
We regard everything as a versioned entity, from the language and libraries we use, the tools for the build and the testing environments, the
programming elements that we build components from, through to the components themselves, the reactors we build from the components and
even the build definition for the subsystems or systems we create. Obviously some versions of things have higher value than others but we like
the entire history, we learn from our mistakes like anyone else.
When you want to make a change or an addition to the systems we delivered, we work out the best strategy required to minimise the effort and disruption to achieve the desired end result. We start from a known (to us) version and deliver a new and recorded version to you.
Our methodologies usually help in minimizing change, adding a capability could simply mean altering an existing component benefiting all instances of that component or perhaps require the creation of a specialized version of a component, perhaps just a simple configuration change or indeed the creation of new components, reactors or endpoints.
We use Git for version control and suspect that you do too, however if you prefer (or have inherited) alternative source control systems we will deliver our principal and snapshot releases in an appropriate form for you to enter your source management system (within reason of course).
We will obviously need to discuss issue tracking more fully to make this work effectively for both parties.