Well, to be honest, that’s not at all surprising. It’s an all too common scenario.
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.
I am not a software developer but I do have project management experience. One of the problems for project managers is that developers want to work with Agile whilst customers often want a waterfall style report. This problem for me is fundamental. It’s the realization that there is a difference between Agile (a software development as a methodology, on which I am not an expert) and agile (small a) as a principle of a successful modern business. Coming back to the Manifesto of Agile helps us out here. These are simply good general principles. Even in their wording they recognize that asserting one way to be right and another to be wrong belongs to an older era where slow paced change was acceptable. In other words let’s be agile about Agile and not set in concrete.
These good principles need to start from the top. “Individuals and interactions over processes and tools” embodies the root of the question. Bosses should hire people they trust…and then trust them. This doesn’t just apply to developers. Once managers get this principle, Agile development follows smoothly. Until managers get it, we will face this continual, painful, seismic fault, with occasional earthquakes and aftershocks felt on both sides of the divide. (With PMs invariably caught in the middle!)
Bosses should hire people they trust…and then trust them
This reaches back to the recruitment processes which are not designed to select the right people but focus on certificates. It reaches even further back into the education system that directs children toward certificate attainment. (Excellent TED talks on this https://www.ted.com/talks/sugata_mitra_build_a_school_in_the_cloud and http://www.ted.com/talks/ken_robinson_says_schools_kill_creativity) We should, of course, 1st teach children to care for other people and to respect them, and then teach them how to learn. Employees also need to do their part, being willing to be flexible with their role depending on what is needed at the time instead of sticking rigidly to an old job description.
So whilst I don’t disagree with teaching Agile (or Scrum, or any other agile development process) to development teams, I really believe that we need to start with teaching the philosophy and principles behind the Agile Manifesto.
Your might be considering Cloud for any of the following reasons:
You Need Cheap Secure Offsite Backup. The Cloud can be an effective way to achieve this.
Your Server Hardware is Old. You have some applications running on a server that is aging and ought to be replaced. If “Cash is King” then saving the capital expense might be useful.
You’d Like to Reduce Your IT Costs. Sometimes a service that is currently provided in house such as email can be delivered more effectively (and possibly cheaper) by a Cloud Service Provider (CSP).
Whatever your drivers are, it is essential that you resolve the following important issues!
Choosing the CSP. There are a number of providers. Which one(s) are a good fit for your business?
Account set up. The last thing you need is to set up the account in a way that will leave you frustrated later.
Cost Management. You need to be certain that costs cannot escalate horribly because of a poor design.
Security is essential. How can you be 100% sure that your data (and your customer’s) data is secure?
This blog expands on the topics above. I would be delighted to assist you with investigating and providing solutions for any of these. Insperitas is also able to provide support for Cloud solutions.
Choosing The CSP.
The three largest providers are also the most flexible
Amazon Web Services (AWS) is the largest CSP on the planet and offers a very wide range of services. The tools are relatively well known and can be adapted easily. For many this is the go-to place when beginning a Cloud Journey. https://aws.amazon.com/choosing-a-cloud-platform/
Microsoft are good at providing a Cloud version of services that they would traditionally provide by selling applications. Email is a classic example. For larger companies MS also offer a mature Identity and Access Management Solution based on Active Directory. Microsoft have a large network of partners and are “Enterprise Ready” in the sense that they are the oldest and most mature of the Big 3 CSPs.
Google are slightly newer to providing Cloud Services when compared to AWS. Google Cloud Platform (GCP) provides a much smaller array of services than AWS. However the services which they do provide are very well executed. They have a stated aim to be the largest CSP in the world in the next few years. https://cloud.google.com/why-google/
Setting up the account
The important things to ensure when it comes to setting up your account in either AWS or in GCP are:
Dont get locked out! You need MFA but who will have ultimate control?
For AWS choose a good Phone number.
For Google, will you get an enterprise account or a Gmail account?
How can you give access to another account for support?
If you have teenagers in your house you will well understand the difference in attitude to electricity use between bill-payers and non-bill-payers (also known as freeloaders). When you are using your own hosted infrastructure you only have to make sure that you don’t fill up the hard drive or place too many demands on memory and processor. However when you use Cloud Services you need to be sure from day one that you will be warned if your monthly costs are going above your anticipated levels.
In addition you need to be sure that your costs are allocated correctly. This isn’t difficult but demands that you follow good Cloud practices right from the start.
Security
When I setup one of my first Cloud servers I was a little surprised to find out a week later that a virus had been installed on the server. I had left open a port to the server that could have been disastrous. These days whenever I build any service online I start with ensuring that it is secure. This isn’t complicated but it is necessary.
For a FREE assessment type code 1709FREE into the “Message” bar on our Contact page
Design your services and components to cope with failure. Any single component failure should not impact the overall service.
When designing Cloud Solutions ensure that the load is spread in a way that will cater for failure. The extent of the spread will depend on the criticality of the service as more spread equates to higher cost.
Use Load Balancers effectively to separate stateless micro-services from each other.
In order to ensure that costs are kept to a minimum it should be possible at all times to know all there is to know about each service. Its important to realize that when using elastic virtual servers, the logs could be deleted when the server is deleted. Therefore servers should log all data centrally in a way that can be readily interrogated.
Log everything. Modern Cloud Services provide detailed logs. Collect them ALL. These include Application Logs, Infrastructure Logs and Security Logs!
Good elasticity depends on having accurate usage data.
Failing to measure is a sure fire way to waste money.
Set alerts on services based on the metrics expected and your design.
Use Tags properly. Your 1st tag for each item should be Cost_Centre. Tagging Taxonomy is important to save future headaches.
A good logging tool is essential for intelligent interpretation.
These are principles rather than laws. They apply in every situation, but how they are applied will differ depending on circumstances. If you would like to know more about how they will apply to YOUR organization, just send me a message from the contact page.
(In no particular order)
Principle
Brief Description
1. Cloud First
Consider using a Cloud Solution before you look at other options. Why Cloud 1st?
2. Automate Everything
Everything you build should be both automated and repeatable Read why here
Because all services offered through the major cloud providers are exposed via APIs then you can start to codify your infrastructure.
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.
