All Posts in “AWS”

Back to Blogging: AWS Terminology

Shhh listen … no no stop talking and just listen. 

That’s the sound of a blog too long silenced being reawakened with a new and invigorated passion.

My focus has shifted from that of the world of virtualization to that of the world of cloud first. It truly feels like such a natural part of the evolution of technology and my career. I thought what better time to break out of my silence than with VDM30in30. This year we are going to focus less on the career and ephemeral and try and get into some AWS goodness. Nothing private or NDA will be shared with reInvent so close you can wait. But I want to share what I have learned and what I am doing.

Because language is important, terminology is the first thing we need to tackle so the rest of these posts make sense, I am going to give you a quick and dirty guide to AWS terms and how they map to what you may already know from VMware systems administration.

Region – a region is a geographic boundary that contains multiple availability zones (see availability zone), multiple regions can be used for DR\CooP scenarios beyond a multiple availability zone deployment. Regions are subject to distance & latency from each other.

Availability Zone (AZ) – an availability zone is a single or group of physical facilities that house AWS resources. AZ’s are highly available and low latency within a region. Applications and services can be used within a regions AZs to provide high availability and continuity of operations.

Virtual Private Cloud (VPC) – a VPC is essentially an isolation boundary for a customer’s AWS environment. VPC’s can be peered 1:1 but the communications are not transitive connections must exist in a hub spoke or lollipop design using direct connect. You will have a default VPC when you create your AWS account, don’t use this for your environment create a new VPC we will get into why in another post.

Instances – Instances are the cloud term for VMs and other services being used within the AWS environment. (ie – you are running an EC2 T2 Micro instance, or you have an instance of RDS running in multi-AZ mode)

Security Groups (SGs) – Security Groups are stateful firewalls. That’s really the best way to think of them and will save you headaches later if you wrap your head around this.

Services – Everything in AWS is a service presented by a series of API endpoints anything you can consume in AWS is a service.

EC2 Elastic Cloud Compute – This is the compute\vm environment there are multiple families that we will touch on in a later post

EBS Elastic Block Storage – Block storage for EC2 instances, can be shared across instances, set into RAID groups, snapshotted

S3 Simple Storage Service – Object storage that is HA across all AZ’s in which it is created

Lollipop network – a lollipop network is the term used for the way a direct connect environment uses the on-premises router to act as the VPC peering point, using VLAN abstractions to route the various subnets.

Reserved Instances (RIs) – a reserved instance is a billing construct where instance resources are reserved, leading to substantial savings.  There are two types of RIs there are Standard or Convertible. (not like the car) A Standard RI is purchased and tied to an AZ, whereas a convertible RI is tied to a region. For you VMware folks RIs are like Resource Pools used in vRA you can set the allocated resources for a tenant to consume and they are guaranteed those resources. On Demand instances land in AZs somewhat dependent on resources available, RIs of both types can and do block off resources for your account.  We will delve into this deeper in another blog.

Amazon Machine Images (AMIs) – <noun pronounced A-Meez or AM-eez depending on what part of the country you are from> –   These are like your VMware templates, they are base OS images or partner provided machine images like OVAs that you can easily deploy in your VPC.

Elastic Load Balancers (ELBs) – ELBs are used for load balancing applications and instances both inter and intra AZ.

Tags – This one is interesting tags are used in various ways both as instance names and as a way to indicate an instance is part of a group of machines performing a set function. Use tags often you can have a max of 50 tags per resource. The best practice is to tag for simplicity

Roles – roles assume policies

Policies – provide granular permissions to resources

Identity Access Manager (IAM) – This is the crux of the operation creating user and service accounts, managing policy and role access and securing resources. Root account, Federation and Multi-Factor Authentication are all managed via IAM.

Multi-Factor Authentication (MFA) – It’s not but it should be mandatory for root accounts and really any account that’s accessing the AWS console.

This should be a good start I am sure I will loop back and update this periodically as new services or terms come up and need explaining.

Time to Pivot

“Opportunities multiply as they are seized” – Sun Tzu 

I get it quoting the Art of War is a bit cliche but it really fits my mood while writing this. The recent news about Verizon acquiring Yahoo got me on this kick because Yahoo failed to seize its opportunities. Yahoo had a chance to buy Google, and sell to Microsoft. Both would have been brilliant moves now that we look back at them with the 20/20 vision that is hindsight. At the time the strategy around such changes would have seemed very risky.

“Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.” – Sun Tzu

By now you know how much I respect Simon Wardley and look towards using maps to plan strategy. I do this with just about every facet of work and career planning. When I joined SolidFire back in November I made a map and saw that move from EMC made a ton of sense SolidFire had huge upside and the job would be something I had never done before. A mix of challenge along with, the opportunity to work with a team of awesome people, and the promise of a software focused infrastructure solution met the criteria for a maturing storage company with huge upside. I was just late to the game as it appears that NetApp had seen similar benefits to what SolidFire could be. Two weeks after joining SolidFire the team was informed that the acquisition was imminent.

The process of acquisition was one I hadn’t fully experienced. NetApp was a big company and they had many processes and hoops that needed to be jumped through. When it was settled I finally got a chance to look at the inside of another big storage company.

Like EMC NetApp has a lot of really smart people working for them. Like EMC, NetApp talks about transformation.ike EMC, NetApp is looking to pivot from storage to the next generation data center solutions. SolidFire will be part of that solution, but what NetApp has to overcome is their legacy mentality and the success syndrome of “this has always worked before, why change”. Some of the best minds at NetApp haven’t been able to come to grips yet with the reality that storage, while relevant, isn’t the critical path that it once was. Too much time is spent talking about competition and not enough looking at how innovation can lead to success and what that next generation needs to look like.

This post isn’t about negativity though, I am sure that NetApp can still pivot and find it’s voice in the changing IT ecosystem. If it can find it’s voice internally that accepts change and sees the value in it’s competition and can speak to the value that NetApp can bring to it’s customers moving forward.

For me though the timing of all of this didn’t work out. For the last several years I have found myself talking about how this product or that helps bridge the gap from private to public cloud. The thought process that we all bought into was hybrid cloud is the future, I don’t know that my opinion has gone that far adrift from this, but what I do know is everytime I have talked about public cloud the names that come up are Amazon, Microsoft, other service providers in that order.

“To know your Enemy, you must become your Enemy.” – Sun Tzu

Back in May I started the ACloud.Guru AWS training course, what I have learned is that AWS is one of the most mature cloud solutions out there. I had played with the EC2 environment before with tying it into vRA but I had never taken the time to see the full expanse of available services. Honestly Amazon has thought of just about everything. An opportunity came available via a friend and former co-worker at Amazon to interview for the AWS DoD team, after going through what is perhaps the most grueling hiring process I have ever faced I was offered a position at Amazon. Part of the process is to give a presentation to the hiring team on  AWS service capabilities. Being the person I am, I also built a demo and performed a live demo as part of the presentation. It went well and I was offered a position as a Solutions Architect.

That brings me to the point of all of this I suppose. Effective August 1st I will be moving to the Amazon Web Services Federal team supporting the Department of Defense. The chance to stop competing against the leading cloud solution and finally be part of the revolution and move to public cloud was one I couldn’t pass on.

No one ever wants to admit defeat, and maybe my time at NetApp was not as successful as I would have liked. I wasn’t able to accomplish everything that I set out to do, I am sure the team that SolidFire has, will make a difference and I wish them the best in their pivot. Thank you to the Tech Solutions team and Aaron Delp for accepting me so openly and for helping me learn and grow. To the vCommunity at large it was so much fun the last couple of years presenting and getting to know all of you. I won’t be attending many VMUGs or vEvents for awhile as AWS has a different focus but stay in touch and I will keep posting about my experiences and what I am learning. The community is still small and we will all see each other around.