Categories
All Cloud Computing Devops

30 questions to ask as you plan for multicloud

via GIPHY

I enjoy reading Corey Quinn’s Last week in AWS newsletter. And also really like his podcast Screaming in the cloud. This week Corey talks with Jay Gordon from Mongodb. While Jay seems somewhat of an advocate of multicloud, Corey is decidedly critical. Which makes for a great interview!

Corey also wrote a piece The Myth of cloud agnosticism. I like any writing that dubs a popular trope as a “myth” because it’s an opportunity to poke holes in optimism.

It is through this process that we become realistic, which is crucial to being reliable in operations and engineering.

Corey argues that multicloud, with respect to multiple infrastructure providers is usually a crappy idea. That’s because the cloud providers are evolving, your application is evolving, and it costs you in terms of feature velocity. What’s more it provides dubious instant uptime in the DR realm.

Join 38,000 others and follow Sean Hull on twitter @hullsean.

The topic reminds me of similar myths in computer science… the myth of cross platform development or
the myth of the cross platform databases the myth of object relational modeling.

As always your mileage may vary. Here are my questions. Hope they can help provide perspective, and critical thinking around this.

1. Do you plan to use multiple cloud providers for infrastructure? And deploy your application twice?
2. Do you plan to use multiple SaaS providers?
3. Does hybrid cloud make sense? That’s an option where you deploy a data link to a public cloud, keeping some assets in your own datacenter.
4. Are their feature parallels across your chosen clouds? Or are there feature mismatches?
5. Your cloud providers have independent service level agreements. Are they consistent or not?

Related: When you have to take the fall

6. What does the outage history look like for each of your providers?
7. What is the potential for fatfinger outage on each platform? For example one may be unduly complicated and prone to mistakes, based on API or dashboard interface.
8. Is one cloud more complicated to implement? For example Amazon Web Services while being more feature rich, is also much more complicated to deploy than a Digital Ocean setup.
9. You can see your backups on both platforms. Have you done restores on both? Regularly? Recently?
10. Do you have time to automate everything twice? For example you may need to rewrite your ansible playbooks for each platform

Related: When clients don’t pay

11. What is driving your business to embrace the idea of multicloud?
12. Do you have time to rewrite scripts twice? one-off and user-data scripts alike?
13. Do you have time to firedrill twice? Smoketest twice?
14. Will different clouds fail in different ways? For example one might be weak around it’s network. Another might be weak around it’s database service, and a third might encounter multi-tenant traffic congestion (disk or network).
15. When one cloud doesn’t support a feature, Ex: lifecycle policies on S3 buckets, do you need to build it for the other cloud?

Related: Is Amazon too big to fail?

16. Will deploying multicloud encourage abstraction layers Ex: object relational modelers (ORM) which heavily slow down performance?
17. Have you tested performance on both clouds?
18. Is cloud #2 a temporary disaster recovery solution or an on-going load balancing solution via geo-dns?
19. If you go hybrid cloud, how does that impact security, firewalls, and access controls?
20. How do you monitor your object stores (S3), scanning for open buckets? Do you rewrite this code for the other API?

Related: Why i ask for a deposit

21. What are the disaster types you’re planning for?
22. What is the cost of maintaining your application on multiple platforms?
23. What is the cost of building infra for multiple platforms?
24. What is the cost of debugging & troubleshooting on multiple platforms?
25. How does multcloud complicate deployments?

Related: How to hire a developer that doesn’t suck

26. Does multicloud complicate GDPR and other compliance questions?
27. How does multicloud complicate your billing and budget management?
28. What about microservices? How will these multiple platforms play across two clouds?
29. Is the community around each cloud equally active?
30. If you deploy with an infrastructure as code language like Terraform, is there an active community there for both of your chosen clouds?

Related: Why generalists are better at scaling the web

31. Does each provider support customers well? What are their respective reputations?
32. Is each cloud provider equally solvent & invested in the business? Will they be around in a year? five years? ten years?
33. What complications arise when migrating to or from this provider?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Cloud Computing Devops

I tried to understand Amazon EKS internals and here’s what happened

via GIPHY

EKS is a service to run kubernetes, so you don’t have to install the software, or manage or patch it. Just like GKS on Google, kubernetes as a service is really the way to go if you want to build kubernetes apps on AWS.

Join 38,000 others and follow Sean Hull on twitter @hullsean.

So where do we get started? AWS docs are still coming together, so it’s not easy. I would start with Jerry Hargrove’s amazing EKS diagram. If a picture is worth a thousand words, this one is work 10,000!

1. Build your EKS cluster

I already did this in Terraform. There aren’t a lot of howtos, so I wrote one.

Basically you setup the service role, the cluster, then the worker nodes. Once you’ve done that you’re ready to run the demo app.

Related: When you have to take the fall

2. Build your app spec

These are very similar to ECS tasks. You’ll need to make slight changes. mountPoints become VolumeMounts, links get removed, and workingDirectory becomes workingDir and so on. Most of these changes are obvious, but the json syntax is obviously the biggest bear you’ll wrestle with.

When done do this:

$ kubectl apply -f my-controller.json

Related: When clients don’t pay

3. Build the service spec

The service is quite a bit different than an ECS service. I suggest starting from the guestbook service. Find it here

Edit that and add your own app name & details. Then apply:

$ kubectl apply -f my-service.json

Related: Why i ask for a deposit

4. Get the endpoint and go!

$ kubectl get service -o wide

You should see the EXTERNAL-IP display a loadbalancer endpoint. Copy that into your browser and you should see your app running.

Related: Why i ask for a deposit

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Cloud Computing Cloud Migrations Devops

How do we migrate our business to the public cloud?

via GIPHY

The public cloud is no longer a bleeding edge technology for the trailblazers. It’s mainstream now. As you think about it, you consider your customers and the SLAs they’ve come to expect.

Join 38,000 others and follow Sean Hull on twitter @hullsean.

It’s not if, but when to move to the cloud, how to get there, and how fast will be the transition?

Here are my thoughts on what to start thinking about.

1. Ramp up team, skills & paradigm thinking

Teams with experience in traditional datacenters have certain ways of architecting solutions, and thinking about problems. For example they may choose NFS servers to host objects, where in the cloud you will use object storage such as S3.

S3 has all sorts of new features, like lifecycle policies, and super super redundant eleven 9’s of durability. But your applications may need to be retrofitted to work with it, and your devs may need to learn about new features and functionality.

What about networking? This changes a lot in the cloud, with VPCs, and virtual appliances like NATs and Gateways. And what about security groups?

Interacting with this new world of cloud resources, requires new skillsets and new ways of thinking. So priority one will be getting your engineering teams learning, and upgrading skills. I wrote a piece about this how do I migrate my skills to the cloud?

Related: When you have to take the fall

2. Adapt to a new security model

With the old style datacenter, you typically have a firewall, and everything gets blocked & controlled. The new world of cloud computing uses security groups. These can be applied at the network level, across your VPC, or at the server level. And of course you can have many security groups with overlapping jurisdictions. Here’s how you setup a VPC with Terraform

So understanding how things work in the public cloud is quite new and challenging. There are ingress and egress rules, ways to audit with network flow logs, and more.

However again, it’s one thing to have the features available, it’s quite another to put them to proper use.

Related: When clients don’t pay

3. Adapt to fragile components & networks

While the public cloud collectively is extremely resilient, the individual components such as EC2 instances are decidedly not reliable. It’s expected that they can and will die frequently. It’s your job as the customer to build things in a self-healing way.

That means VPCs with multiple subnets, across availability zones (multi-az). And that means redundant instances for everything. What’s more you front your servers with load balancers (classic or application). These themselves are redundant.

Whether you are building a containerized application and deploying on ECS or a traditional auto-scaling webserver with database backend, you’ll need to plan for failure. And that means code that detects, and reacts to such failures without downtime to the end user.

Related: Why i ask for a deposit

4. Build infrastructure as code

You’ve heard about devops, now it’s time to put it into practice. Building your complete stack in code, is very possible with tools like Terraform. But you may have trouble along the way. I wrote I tried to write infra as code with Terraform and AWS and it didn’t go as expected

So there’s a learning curve. Both for your operations teams who have previously called Rackspace to get a new server provisioned. And also for your business, learning what incurs an outage, and the tricky finicky sides to managing your public cloud through code.

Related: Why i ask for a deposit

5. Audit, log & monitor

As you automate more and more pieces, you may have less confidence in the overall scope of your deployments. How many servers am I using right now? How many S3 buckets? What about elastic IPs?

As your automation can itself spinup new temporary environments, those resource counts will change from moment to moment. Even a spike in user engagement or a sudden flash sale, can change your cloud footprint in an instant.

That’s where heavy use of logging such as ELK (elasticsearch, logstash and kibana) can really help. Sure AWS offers CloudWatch and CloudTrail, but again you must put it all to good use.

Related: Why i ask for a deposit

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters