#screaming crying throwing up about this new html setup | Explore Tumblr Posts and Blogs

mikegchambers · 7 years

Text

Baby steps to the cloud: migrating your corporate website

Cloud isn’t just for new projects —migrating an existing application like a website is often the preferred first step

It’s easy to get the impression that the cloud is so alien to on-premise IT that you have to wait until a new project comes along to try it out. Fortunately for patience-impaired like me, we can easily migrate existing workloads across and see immediate benefits.

Getting one migration project off the ground is the key to convincing the Powers That Be that 100% cloud is where the company wants to be in the future. This step is all about building credibility to achieve our ultimate goal of becoming cloud natives.

Quick Recap: Key Benefits of Cloud

While cost savings are usually the hook, that’s not what cloud is really about. At its core, cloud provides three benefits that are either needlessly hard or impossible to do yourself:

Availability: what percentage of time is your application ready for its users? While no system can ever reach 100%, we’re generally trying to do everything we can to be close to perfect. Being unavailable is the tech equivalent of a power outage — the TV is still on the wall but it’s blank.

Durability: how much of the system (code and data) are you expecting to lose? Hard disks will always fail, tornadoes will swallow up buildings and well-meaning people will always do stupid things. Durability is all about surviving the unholy trinity of entropy, disaster and human stupidity. In my TV analogy, the TV has been stolen.

Scalability: what can the system do to cope with increases and decreases in load? When your product gets a deal on Shark Tank, will it cope with a 10,000 times increase in traffic? This is a ‘chicken and egg’ dilemma with your own hardware because you inevitably end up with too few or too many resources. In real life, this is like having more TVs appear when you want to watch multiple channels, but vanishing when no longer needed.

Basically, is it working? Is it there? Do I have enough resources? Fault tolerance and high availability are snooze-inducing buzzwords for the average human, but flip the words around and they just mean your application can tolerate faults and will be available more than you would expect. In practice, pulling off this magic trick is all about finding bottlenecks and points of failure. In essence, you are creating a plan B for everything, always assuming plan A is going up in smoke.

I was going to say how the most unexpected things fail but a picture speaks 1000 words.

But you also need to determine which website is worth the effort. For a corporate webpage that manages employee’s tennis court reservations, who really cares if it only works 95% of the time running on someone desktop PC? Big deal if it breaks (apologies to tennis fans). But if your site is streaming video for the Game of Thrones finale, you damned well better achieve 100% availability (I’m looking at you, HBONow). This is clearly much better candidate for migration.

Example Project: Your Company’s Website

It’s not new, it’s not sexy, but your company’s website is important and it’s one of the few ways your customers get a glimpse into your internal technology horror show. It’s a good place to start for a cloud migration since the transition is well understood and your glorious success will be highly visible.

There are many ways to build a website on-premise but here is one of the most common approach:

A typical website configuration makes cloud people cry.

Bad, bad, bad. This is a sorry design based largely on the ‘hope and pray’ approach that has a unhappy track record for disappointment. If one piece fails, it all fails. Cue screaming customers, mad executives and pagers beeping at 3am.

Anecdotal personal experience, not scientific.

Apart from the declining availability that happens when you multiply lots of 99% probabilities together, it also cannot be upgraded without downtime. This is just about the laziest setup for a website (though surprisingly common) and while might be fine for a hobby blog — would be a train wreck for anything remotely popular. Let’s make it work properly a la cloud.

Pray that nobody kicks the server and the hard disk lasts forever because it scores low on our Big Three.

Version 1: Just add cloud!

In practice there are just as many ways to cloudify a project but here’s my first sketch at using AWS to lift this website into the 21st century. Marvel at my graphic for a few moments and I’ll explain on the other side…

Fun fact: 90% of the world’s cat videos are stored on S3.

This isn’t as complicated as it looks but it was fun to draw. Piece by piece, this is what we have:

VPC: the dotted line is like the electric fence around your cloud playground. “Virtual Private Cloud” is tech talk for your very own piece of cloud real estate.

Route 53 lets us point traffic at the domain name level wherever we want at massive scale. This is a smart managed networking service that we can later use to do all sorts of cleverness (like routing regional users or fighting off denial of service attacks).

CloudFront is a content delivery network (CDN). These are extremely powerful, very cheap and loaded with kick-ass. Usually 90% of website content is static (e.g. images and video) so with a CDN — quick win alert! — you can offload this and release significant server resources. But wait, there’s more! The CDN can distribute to servers geographically closest to your visitor, so it also helps speed up your site for customers far, far away.

S3: Amazon’s mindbogglingly large storage system can securely store files, feed CloudFront, and even hold machine images for servers. In this example, we’ll keep 90% of our data here because it’s super-reliable, highly secure and cheap.

Regions: the diagram shows one region but it can be duplicated exactly to others. If you open an office in Asia, we can just roll out a copy to this region, update Route53 (so local customers hit their local region) and we’ll be done by dinnertime. Need a third region in Europe? Done.

Availability Zones: each region has at least two AZs. Why? Because power fails, networks go down and life happens. We mitigate this by having our infrastructure across two AZs so our customers will never know when an outage occurred.

Elastic Load Balancer (ELB): this takes every incoming request, determines which instances are available to help, and sends it over. If a zone is down, the ELB will be the piece that switches everything across. ELBs are the unsung heroes in orchestrating most of the cloud dance.

Auto-scaling: this is simpler than it sounds. When our instances get too busy (or freeze or die), auto-scaling steps in, powers up some new boxes, installs all the software we need and tells the ELB that it has more places to send work to. It’s the manager that watches the checkout line and says, ‘We need another register open’.

Instances: cloud lingo for ‘servers’. There was just one ‘webserver’ in the first diagram, now we have a fleet of interchangeable machines all doing the same thing. We can add more, take them offline, perform upgrades as needed and generally operate without impacting visitors negatively. We build these instances based off our custom images.

ElastiCache: caches remember the answers to questions and since webservers get asked the same questions frequently (‘hey, what’s the homepage look like?’), they can take the load off the database that would otherwise be doing the work. Caches are much faster than databases and are particularly useful for read-heavy applications like websites.

Database (RDS): scaling databases is hard, replication is scary, and most companies do it badly. RDS is a managed service that does this for you, allowing us to scale quickly with read replicas while also doing its own housekeeping, like backups and maintenance.

This Looks Expensive — and Complicated

I know what you’re thinking. “I just wanted a Honda Civic and you gave me a Tesla delivered by a SpaceX rocket.” I did, but fortunately it’s cheaper and more reliable than the Honda (if that’s even possible, hey Honda fans?).

This is the sort of environment you can build out in a few hours on AWS and might easily have an average running cost of a few hundred dollars a month (depending on your usage). The reason it’s so fast and cheap isn’t because I’m the best cloud guy in the world with extremely reasonable rates and a great can-do attitude, it’s because cloud is code. Let’s repeat that together (the cloud part):

Cloud is code. Infrastructure is code. Build it up. Throw it away.

Nobody is ordering servers, racking hardware or approving purchase orders. We simply build out a CloudFormation template (like a blue print for your house), click “Create” and automation happens. An army of bots builds exactly what we want and we’re done. The hardest part will be migrating files and content, and even that can be fairly simple with a few scripts.

Version 2: Simpler, Faster, Better

Ok, version one solved many of our problems presented in the Dire Stack of On-Premise Failure. It gave us much more availability, durability was effectively solved, and while scalability was impressive, it could still be improved.

Imagine you have a webpage that’s going to get massive amounts of traffic unpredictably across multiple geographic regions. Suddenly you get one million visitors from Australia when a TV ad runs during a national event, and then nothing for 24 hours. And now the traffic hits the West Coast, 10 million visitors during TV ads on cable in the evening, and then it goes quiet. How do you scale up fast enough or make sure the right regions are in place?

In order to accommodate this extreme traffic, I present for your consideration “version 2”:

In the classic website model, you need a web server, database and code to connect it together. In this new version:

Static HTML pages are served on the global CDN (CloudFront). These are just files thrown out to the user’s browser on request.

JavaScript pulls dynamic content through Lambda (via an API). This runs on the client (keeping the hard work on their side).

Lambda connects to ElastiCache, DynamoDB or RDS for the data. This is a massively-scalable tool that runs small chunks of code.

You might remember from last week’s blog post on Mobile Apps that this is a serverless implementation that effectively handles the scaling for you. It’s exceptionally resilient to denial of service attacks and offers blazing performance for a distributed visitor base. It’s also much cheaper to implement than version 1. While it’s not going to work for CMS-based sites that rely on the more traditional stack, it’s an A+ alternative for high traffic landing pages with a spiky demand curve, such as those targeted by TV ads.

What’s the smallest step you can take?

Sometimes the Big Bang migration can be alarming so it’s also worth mentioning a couple of small move alternatives that would greatly improve your overall website infrastructure with just a little cloud.

CDNs can and should be deployed to any and all public-facing websites. CDNs are cheaper than coffee. We’re talking pennies per gigabyte and this single step will have a huge performance improvement for any website. Seriously, it’s a no-brainer.

Lift and shift: if you moved the webserver and database from the first diagram into the cloud, you would expect a slight performance bump (cloud providers’ networks are faster than yours) and it could promote further baby steps to total cloudification. Over time it can morph into the version 1 diagram fairly easily.

Serve a backup site from S3: if your IT people are refusing to budge, one idea is to serve a backup version of the site from S3. This means whenever your site is down, a static version is served in its place. This will only work for certain types of site but it does allow you to handle failure a little more gracefully, and then opens the door to future cloud migration.

Store your code in cloud repositories. It’s a sensible safeguard but this practice also gets your development and IT groups familiar with automation tools. Automation is catnip to developers and it’s the Trojan horse to cloud.

There’s nothing alarming about automation at all.

Imagine the Possibilities for Your Applications

There are many ways to bring cloud into existing applications and workloads in your organization. The ephemeral nature of virtual hardware can be difficult to grasp and somewhat unsettling.

Pre-cloud, we built everything like it was poured concrete, a major production that was hard to change and move. Cloud providers gave us small ready-made pieces that are like Lego bricks. We can add, change, build up, tear down and have this enormous flexibility that takes a while to fully appreciate.

In most companies, getting ‘on premise’ servers versus cloud servers, it’s like comparing communist-era food rationing to Costco.

This simple example is just a website. Imagine what you could do for a distributed point of sale system in retail. You could create cloud-based services that securely support your cash registers, website and mobile e-commerce app. Write once, use everywhere. Mind blown.

Did you enjoy this? Click the little heart below!

Baby steps to the cloud: migrating your corporate website was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.

from A Cloud Guru - Medium http://ift.tt/2pf6OLF

#A Cloud Guru - Medium

0 notes