First post on a new blog. In the spirit of what I plan to do with the site, this one will be about architecture generally in the cloud. Cloud is not the same as traditional on premises infrastructure. Unless you’re one of the lucky few who actually had a private cloud then you’ll probably be wanting to change the way you plan, design and implement your solutions. You’ll probably also want to address how you secure things too, but that may be getting ahead of ourselves.
|If you want to invent a car, you have to forget how much you love your horse.|
To be a cloud, the platform needs five things. These are on-demand self-service, broad network access, resource pooling, rapid elasticity or expansion, and measured service. It’s the rapid elasticity and resource pooling we’re looking at today. In a traditional data centre you’d have bought a network switch. Probably more than one network switch. This would be your “network”. I know this sounds basic, but bear with me as we need to unlearn a few things we know before moving on; forget your horse. When setting up that network an address range was chosen and configured and surrounded by firewalls to control traffic. All our “stuff” then plugs into the switch regardless of what it’s for because we’re on the network.
Fast forward and we’re talking about micro-segmentation, a technology designed to put firewalls around small bits of network to protect apps individually. We still have a network, of course, but now it’s protected and segregated. It does suffer with scalability though because we have to choose a bunch of parameters up front such as address range, switch model and so on.
Enter the cloud. I see a lot of people configuring big networks in the cloud because they configured big networks on premises. They then segment the network and firewall it like they did on premises just so that applications can communicate on a private IP address. This works, of course, why wouldn’t it? The horse can still get us where we need to go even though trains and cars offer an alternative. Let’s think outside the box for a moment though about what we’re creating here.
Each application lives in a micro-segment competely surrounded by firewalls which only let traffic in to specific end points. Ideally these end points are actually load balancers fronting a scale out solution of some kind, but they are nevertheless endpoints which are well defined. Since each application communicates only with known endpoints which are behind firewalls anyway, they are effectively on individual networks. The application is properly secured and traffic encrypted, so there is no reason another application should need to communicate with it on a special internal IP address. The above image shows two segregated networks which have been designed not to overlap simply to allow direct communication. This makes automation much harder than it should be since we have to provision a new address range each and every time we deploy something new. That range must be designed not to overlap and must be large enough to scale with the application. Why then would we restrict ourselves to addressing which doesn’t overlap, which needs sizing ahead of time, which inevitably causes a headache down the road? Why not provision a new network for each application; encapsulate the application and open an endpoint for outiders to connect to. This way we can deploy an endless number of applications, none of which affect others.
Here we have networks with identical ranges. This means that we can provision as many as we need, and use the same template for dev, test, UAT, production and any other deployment we need without further thought. The public IP is auto-assigned as the endpoint, and we can use a global load balancer to scale out by adding more environments. Much simpler, just as secure, more scalable, what’s not to like?