Consider before going multi-cloud

Going multi-cloud has obvious goals - increased resilience, and redundancy. Though, it can hurt when it comes to the health of a particular company.

There are 12 other typical project themes, which magically cover active-active multi-region in the result, but does not include network plasticity (redundant multi-region) itself [1]. The multi-region itself happens to be 13th topic, a cherry on top.

"Keeping menu short" [2] is a direct and yet again rationale avoiding multi-cloud.

Specific roots. Preventing downtime here is linked mostly to calculations as majority of the companies would not have that drastic loss from a system-wide failure in the cloud or will have issues predicting it.

Think about a logical mistake during development (SDLC) which makes your object storage return empty files marking responses as valid (code 200, empty body). In this case, canonical persistence system misleads and needs adjustment. Redundancy here is helpful only to a point of segmentation. For example, us-east-1 outages are most visible, but because of that, risk management suggests AWS would prioritize updates going first to less populated regions as well.

The direction reverses when plasticity needed to implement dynamic strategy of change gets closer to all 12 angles. This as “unintended” result raises tolerance and hence operational savings for cases beyond 12.

Let’s come back to multi-cloud. At least when planned and executed as full redundancy for computing resources. Think about it: network, processing, databases, other persistence layers double both design and maintenance at infrastructure, and platform layers. Hence, changes to overall system will:

1. require deeper analysis and planning due to added “universalization” activities
2. be more complex
3. 1 & 2 are increasing cost of immediate execution and support, but also quadruple likelihood of a mistake related to own SDLC operations

When rationale is to predict and prevent system-wide failure which is probabilistic, 1-3 as mix of certain and expected outages outweighs the benefit.

All this though leaves good niches for short-term multi-cloud executions when it comes to:

• consolidation of business branches which are already in this parallel state
• when new cloud offers can significantly benefit cost-wise after the switch

As well as strong opening for specific services:

• when they are added in non-redundant manner with “10x” edge. High quality, white gloves and turnkey software as a service model. Preferably, backed by multi-region active-active blueprints. 

The 3^rd theme, quality, is what will make providers create unique propositions simplifying visible complexity of the tech business and reliability of available technologies.

 

[1] Own your SaaS: 12 angles to improve your velocitywith blueprints

[2] Keep your menu short

FISMA and GovCloud verticals

A few words on blueprinting your website (SaaS) for government verticals.

AI perspective and SaaS blueprints

Regardless of where AI is sitting in your stack today, when it becomes versatile it can help you with code not with manual clicks in consoles. The longer you wait, the more progress slips your IP. It will take some time to catch up when technology is fully there. The longer you would spend on AI. This might disrupt your business.

See also

• Zero-time provisioning
• Own your SaaS: 12 angles to improve your velocity with a SaaS blueprint

Zero-time provisioning

 

Removing manual work was never that effective. There is no security person checking configuration, no operations copying secrets from one place to another, no manager coordinating and prioritizing work between teams, no figuring out dependencies over and over, reduces surface of a costly mistake at least in half. In a fact most secrets are provisioned as part of blueprint and there is no soul which sees those credentials.

This leans feature engineering to crafting itself with minimal wrapping. This means feature can go to end customer with 4-5 times less people involved, and hence 8-10 times faster in a responsible manner. Risk management on early stages gives advantage on later stages. Hence compounding cycle continues as you go to larger customers.

This is a good example which shows five nine analysis prism in action: if something goes south, how can team reconfigure this quickly in a new place? Once this question answered - it turns out this is the same question as how to optimally design a feature in a first place, or how to reuse parts of technology would an organization go to a different direction or vertical.

Focusing on blueprinting of dependency provisioning multiplies software teams as they can provision own configuration once and pass it to relevant application at every stage of SDLC.

This is a way to own your SaaS. 

Contact us here for more information.

See also

• Own your SaaS: 12 angles to improve your velocity with a single blueprint
• When configuration management gap cost $400M

Customer authentication

 

Category: Core service of AnyIntelli blueprint

This workshop goes through the prism of five nine (99.999%) reliability, with main what-if scenarios and under 60 minutes recovery target.

As a core part of AnyIntelli blueprint it focuses on specifics of leveraging the power of AWS, and the blueprint standards to ensure full ownership. In scope of the solution are warm and hot recovery schemas and procedures, IaC and building secure authentication island, distribution of responsibilities between end user interface, backend services, and incorporation of AWS infrastructure despite their respective limitations and idiosyncrasies.

After all leveraging cloud offerings and serverless solutions of a provider always comes with untold challenge: extra sets and layers of restrictions each service has.

This workshop shares analysis and practice which was used in building customer sign in system for AnyIntelli Elevate. Useful when you need to know what will work and what will not with this cost effective solution using only AWS.

Contact us here for more information.