Inspiring Cloud Initiatives
Seriously – Every interaction with Cloud Services should be handled in a secure fashion
For more detail check out this blog.
Build everything as Code
Why?
All Cloud services worthy of the name can be used or accessed using their API. By calling this API via code we can benefit from:
Everything you build should be both automated and repeatable
Why?
What if your infrastructure breaks? What if there is a disaster? Rebuilding can take considerable time. If your solution is built from repeatable code then recovery can also be automated.
Chunks of well crafted repeatable code can be pieced together to form more complex solutions, saving time in the long run.
Continuous Deployment which is a pillar of agile entities can only be achieved with automation.
A complete and well defined automated solution creates a perfect staging environment, protecting your production environment without the need for human change control.
Consider a Cloud Solution BEFORE you consider the alternative
Why?
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 |
| 3. Build Everything using Code | Mouse Clicks on portals aren't automated. 🙂 Benefits of IaC |
| 4. Security is Paramount | Security shouldn't be an after-thought but should be built into everything. Stay Safe |
| 5. Measure Everything | Tag everything. Log everything centrally. Save money and future headaches |
| 6. Create Scalable Microservices | Scale horizontally No monoliths |
| 7. Prepare for Failure | Assume things will break. Build self-healing solutions. here's how |
| 8. Optimize for Cost | Never over-provide! |
| 9. Consider Portability | Will you need to use another Cloud Service Provider? |
| 10. Follow Cloud Native Best Practices | All applications should be designed in line with best practices |
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.
So today I am delighted to announce that Insperitas can now take your messages despite being hosted as static pages on S3. <Fanfare>
When the contact form is completed and you hit Send then your browser should collect your data and send it to AWS API Gateway. Then AWS Lambda will post that into S3. If this doesn’t work well for your specific browser please let me know. You can still email via your normal method to contact@insperitas.com.
I want to take a few minutes to thank the authors and developers whose code I used or whose direction I followed to get this insperitas site to where it is today. I can’t possibly mention every name as I scoured the internet for clues when things went wrong and spent hours on stackoverflow. 🙂
For the contact form: Thanks to Collins Abonghama https://www.sitepoint.com/build-your-own-wordpress-contact-form-plugin-in-5-minutes/
For the lambda suggestions along with API Gateway I have to thank David Maple https://www.codeengine.com/articles/process-form-aws-api-gateway-lambda/
For Form building I followed TGroshon at CodeHabitude https://codehabitude.com/2016/04/05/forms-to-emails-using-aws-lambda-api-gateway/ and also Matt West whose work is posted at https://blog.teamtreehouse.com/create-ajax-contact-form
Also I had some help from my good friend Tim Fuller https://www.linkedin.com/in/tim-fuller-788a2421/ Since I am not a natural developer I needed considerable syntax troubleshooting help.
Of course I also need to thank all the people I have worked on Cloud Solutions with over the course of the past few years at HSBC, FlyBe and Odeon. There are some great minds out there building some incredible solutions.
There are a number of trainers too at AWS, Google and RedHat who have helped enormously. Having run a number of training courses myself its easy to spot the professionalism.
Continuing with the analogy of electricity, if your company decided to build a new motor or machine that would be driven by electricity you would likely build it to utilize the service that is commonly available. ie. 230 Volts, Single Phase, Alternating Current. You might choose something different if you had a particular need but it would be unusual to specify some random voltage just because you can. Also if you had multiple electricity suppliers are available you MAY not want ton tie yourself to a specific provider unless there is a clear benefit.
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. 🙂
Today I am going to start my Cloud 101 blog posts. In this section I will cover all the main Cloud questions so, in time, this site should become a repository of all basic Cloud lessons. I will include links to important upcoming events and also show you where free beneficial online training can be found.
So to start at the beginning: What Is Cloud?
Using the term Cloud to refer to computing services really took off in 2006 as Amazon started to sell access to the computing power that they used to manage the Amazon.com market-place. Google followed suit two years later with Google App Engine. It essentially refers to the practice of providing computer resources that are consumed over the internet. Commonly these resources are Compute and Storage resources but can (and will) be expanded to cover almost all IT Technical Services.
A good analogy is electricity. Very few companies today would find it necessary to to generate their own electricity. Rather it is a service that they consume. It is cheaper and easier to let experts handle power generation and deliver it to your door, to be consumed by your company, paid for in units as you use them.
There are some important definitions that we will cover later that will explain some of the differences between different flavours and styles of Cloud Computing such as SaaS, PaaS and IaaS. Also we will cover Hybrid Cloud Public Cloud and Private Cloud to see if we can understand which of these will be most beneficial for you.
Next See “Using Cloud or Embracing Cloud” as this will help you understand some of the reasons why you should ensure that you and your company are properly engaged with the Cloud world.