Here’s an interesting tidbit from “Last Week in AWS” blog:
From a philosophical point of view, AWS fundamentally considers an API to be a promise. Services that aren’t promoted anymore are still available […] Think about that for a second - a service launched 13 years ago is still actively supported to the point where you can use it today.
The amount of layer-2 tricks we use to make enterprise networking work never ceases to amaze me - from shared IP addresses used by various clustering solutions (because it’s too hard to read the manuals and configure DNS) to shared MAC addresses used by first-hop router redundancy protocols (because it would be really hard to send a Gratuitous ARP message on failover) and all sorts of shenanigans we’re forced to engage in to enable running servers to be moved willy-nilly around the Earth.
Design assignments and hands-on exercises were always a big part of ipSpace.net online courses, and our new Networking in Public Cloud Deployments course is no different.
You’ll start with a simple scenario: deploy a virtual machine running a web server. Don’t worry about your Linux skills, you’ll get the necessary (CCIE-level) instructions and the source code for the web server. Building on that, you’ll create another subnet and deploy another virtual machine acting as a back-end application server.
And then we’ll get to the fun part:
You need Free ipSpace.net Subscription to watch the video, and the Standard ipSpace.net Subscription to register for a deeper dive into cloud security with Matthias Luft (next live session on December 10th: Identity and Access Management).
One of the responses to my Disaster Recovery Faking blog post focused on failure domains:
What is the difference between supporting L2 stretched between two pods in your DC (which everyone does for seamless vMotion), and having a 30ms link between these two pods because they happen to be in different buildings?
I hope you agree that a single broadcast domain is a single failure domain. If not, let agree to disagree and move on - my life is too short to argue about obvious stuff.
You’ve probably heard cloudy evangelists telling CIOs how they won’t need the infrastructure engineers once they move their workloads into a public cloud. As always, whatever sounds too good to be true usually is. Compute resources in public clouds still need to be managed, someone still needs to measure application performance, and backups won’t happen by themselves.
Even more important (for networking engineers), network requirements don’t change just because you decided to use someone else’s computers:
- Joep Piscaer will dive into what changes public clouds bring and what these changes mean for you, as well as what developers and other consumers of cloud resources expect from you in the new public cloud, DevOps and Infrastructure-as-Code world.
- Ned Bellavance will review the principles of Infrastructure as Code (IaC) and how they apply to public cloud solutions. Then he will take a look at the landscape of IaC tools that exist and examine their pros and cons.
- Howard Marks will review the types of storage available across public clouds, how they differ between cloud providers and the applications and pitfalls associated with each of them.
- Connecting on-premises data centers or office locations to a public cloud has some unique challenges. Ed Horley will help you create a framework and a checklist to make sure you have the required redundancy, throughput, routing, and security all baked in from day one.
- Matthias Luft will cover the aspects of securing your public cloud deployments.
- Justin Warren will explain how to make good tradeoffs between resilient hardware and resilient software.
Sounds interesting? The first Networking in Public Cloud Deployments course will start on February 11th, 2020, but the minute you register you'll be able to start studying the materials (over 100 hours of content). There’s just one thing you have to do: click the Register button.
I’ve seen successful public (infrastructure) cloud deployments… but also spectacular failures. The difference between the two usually comes down to whether the team deploying into a public cloud environment realizes they’re dealing with an unfamiliar environment and acts accordingly.
Please note that I’m not talking about organizations migrating their email to Office 365. While that counts as public cloud deployment when an industry analyst tries to paint a rosy picture of public cloud acceptance, I’m more interested in organizations using compute, storage, security and networking public cloud infrastructure.
We’ll start with the basics, explore the ways to automate cloud deployments (after all, you wouldn’t want to repeat the past mistakes and configure everything with a GUI, would you?), touch on compute and storage infrastructure, and the focus on the networking aspects of public cloud deployments including:
You probably heard me say “networking engineer encountering a public cloud feels like Alice in Wonderland” - packet forwarding works in a different way in every public cloud, subnets are a mix between routed interfaces and VRFs, you cannot change IP addresses without involving the orchestration system…
We covered the networking aspects of Amazon Web Services and Azure in our cloud webinars, but you might need a bigger picture:
Listening to (some) industry evangelists you would believe that there’s no future in being a networking engineer. After all, all workloads will move into the cloud, and all clients will connect through a universal 5G network… but even if that utopia eventually comes true, you can’t get away from the laws of physics (and the need networking infrastructure).
Gregor Hohpe published an excellent series on Martin Fowler’s web site focusing on various aspects of lock-in. If nothing else, you SHOULD read the shades of lock-in part, and combine it with my thoughts on lock-in in data center networking.
I have exciting news I’d love to share with you: we’re launching a new online course focused on networking in public clouds starting in February 2020 (I’ve been mulling over this idea and polishing the concept for almost 18 months, and finally it all came together ;)
With Go To The Cloud becoming the answer to all questions (regardless of what the question is), you can find tons of materials describing various aspects of public clouds, so you might wonder why I decided to enter the fray. The answer is simple: with everyone being focused on developers, there’s not much that an infrastructure engineer could use to help him survive when the developers move on and he’s left to manage whatever they put in place.
I recorded the hands-on demos in advance so we had plenty of time to discuss Azure API and CLI, geographies, regions and availability zones, high-availability concepts, and deployments models… and spent the second half of the live session focusing on virtual networks, subnets, interface, and IP addresses. The videos are already online and accessible with Standard ipSpace.net Subscription.
Next step (on September 24th): network security and user-defined routes.
I’m too stupid to unwind and relax over summer - there’s always some janitorial task to be done, and I simply cannot leave it alone. This summer, I decided to migrate our server infrastructure to AWS.
TL&DR: It went smoother than I expected, and figuring out how AWS virtual networks, public IP addresses, and security groups work while creating AWS Networking webinar definitely helped, but it also took way longer than I expected.