Why?

Because companies choose to use Cloud Services for the following reasons.
1. To urgently replace an existing backup solution.
2. Because some new urgent project demands a Cloud based solution.
3. To speedily boost or replace on premise servers.

All of these are time based demands and often they spawn a sudden launch into Cloud without serious consideration of how resources should be managed.

The common problems this creates include:

• No tagging
• No one knows why a server was built or if it can be deleted
• Lack of clear ownership
• Bills cannot be allocated properly
• Disagreement as to who owns the shared Cloud services
• Insecure solutions
• Inefficient solutions
• Inflexible designs

Insperitas can help you by:

Evaluating your whole Cloud infrastructure
Ensuring proper systems and processes to enforce best practices
(read more…)
Remediation of existing issues

But you don’t want or need to become dependent on Insperitas. And you probably wont be able to move immediately to meet best practices. A better solution might be for a consultant can come to your site (or work remotely) for 1  day a week to teach and guide your own employees to implement success.

Together let’s bring your costs back down to earth.

Call me  (+44 7932 678578) or fill in your details on our contact page and start moving towards a more cost effective Cloud engagement.

To explain this in more detail lets look at the different ways we can build a server in AWS. AWS servers are called “EC2 instances” (ECC stands for Elastic Compute Cloud). Once you have an account you can use your browser to visit a console where you can click on a button to build your server. The form will ask you a bunch of questions and then Amazon will build the virtual server for you.

However Amazon also allow you to build your server from the command line. You can download the AWS SDK or you can use the CLI.  These tools will allow us to write code that can be executed to build whatever we need. There are other tools (such as Ansible and Terraform) that can add a level of abstraction and simplification to this process.

Once all of your infrastructure is built as code things start to change in the way the infrastructure is managed. We can start to introduce all the good practices that developers have been using for years to manage code. Simple things such as versioning, keeping backups of previous versions, extensive in-line commenting to name but a few.

Our code can tell our Cloud Service Provider (CSP) what to build but also tell us what we have built removing the need to continually update a database  that references our complex environments. Infrastructure change becomes easier to manage as we can roll back to a previous version in minutes.

But our code can do even more than this. Our code can include references that allow automatic scaling of services. However that demands an understanding of the subject of elasticity and at this point its probably worth reviewing the 10 principles of a good Cloud strategy.

Contact Page

So it is with Cloud Computing. If we think of Cloud as simply a bunch of servers off site then we are missing 95% of the benefits. we could just lift and shift our existing server estate and provision it from a Cloud Service Provider but that is unimaginative and prosaic.

The right approach is “embrace” Cloud. This will necessitate a complete change of mind set within your current IT world!

One reason for this is that Cloud Services are charged for by the minute or by the hour (depending on some basic choices) and therefore you should only build EXACTLY what you need to consume. Most servers only operate at a small fraction of their capacity for most of a day. Traditional server estates are designed to be much larger than needed to be able to cope with spikes in demand. Cloud Servers should be stopped when they are not being used and therefore you wont need to pay for them.  It wouldn’t make sense to have someone on standby to start and stop machines when needed either. So therefore all Cloud Services SHOULD be consumed programmatically!

Once we have taken that important leap in understanding we are well on the way to EMBRACING rather than USING Cloud. In my next post I will get to IaC to describe why this is such a BIG THING.