Turbonomic Blog

Eric Wright

Eric Wright
My philosophy in work is a simple one that comes from years of practical experience. There are three components in an IT organization; those are People, Process and Technology. The order of those is as important as any of the individual components. Simply put, the IT organization empowers business needs through technology. And that technology is driven through people and processes. An IT organization needs to be agile, as well as dependable. Agility comes from a strong group of people who are knowledgeable, dynamic and are able to respond effectively as a team. That same team is required to deliver consistency so that a business can be confident of their position at all times. Throughout my years of experience I have developed some personal principles: 1. The priority is customer satisfaction - We must strive at all times to meet and exceed the customer expectations. 2. Communicate effectively and often - Effective communication is the key to delivering complete solutions. 3. Automate where possible - DRY (Don't Repeat Yourself). Use automation where appropriate to reduce manual processes. 4. Empower the customer through self-service - The best way to ensure adoption is through active customer interaction and simple self-serve processes. 5. Support your team - An effective team works as a collective. Be a mentor, a peer and a student. 6. Balance - Work and Life, Effort and Result. Do your best to balance in all that you do 7. Be Proud - Deliver products and services that you would be proud to put your name on. Specialties: VMware vSphere and vCloud OpenStack Microsoft Solutions Specialist Systems Architecture Systems Integration Specialist
Find me on:

Recent Posts

Turbonomic Master Class – The Art of Super Clusters

Posted by Eric Wright on Jul 27, 2020 10:01:10 AM
It's a bird! It's a plane! No, it's Super Clusters!

One of the most valuable capabilities that organizations enjoy with Turbonomic is the ability to create what we call “super clusters”. A super cluster is a virtual resource pool comprised of physical clusters in your environment.

Read More

Topics: Case Studies, Infrastructure, Performance, cloud optimization, Efficiency, Super Clusters

2 Ways CPU Queueing is Killing Your Application Performance

Posted by Eric Wright on Jul 9, 2020 3:08:31 PM

There are no shortage of confusion talking about how CPU queueing works and how it ultimately affects your application and environment performance. Virtualization gave the industry something wonderful by enabling sharing of physical hardware resources, but it also opened the door to hidden issues that IT ops and application developers still struggle with every day.

Let’s quickly review what CPU queueing is and how processor wait times can have a catastrophic effect further up the stack.

Read More

IaC Powering a Monolith to Multi-VM Architecture – Part 3

Posted by Eric Wright on Jun 25, 2020 2:43:32 PM

Now that we have our requirements and constraints defined from our first post, and our working single VM infrastructure-as-code built from our second post, it’s time to start the big build!

We already built out our desired multi-VM architecture that we have a map of from our initial discussions with the dev team. The bonus from this architecture is that we are also leaning into the services-style approach. That means we may be able to break out our SQL and eventual NoSQL clusters as shared services and even port them to a PaaS on the cloud if desired. Everything we do should be done with an eye on the future desired state.

Codifying our Multi-VM Deployment

Let’s begin with the simplest layout of what our virtual machine infrastructure needs to look like. We have our public code repository which is showing the real version of what we are building. It’s important because we may save some space in the blog by just focusing on some specific snippets. Please refer to the repository for the full code as you test this out yourself.

In the Monolith to Multi-VM folder under Part 2, we built our single monolithic VM using a VMware vSphere template and Terraform to quickly spin up and tear down a clone from that template. That’s the easy bit.

This is where we turn our attention to Monolith to Multi-VM Part 3 which is the more robust version. For now, we are using a basic template and we will worry about the application deployment in part 4. We just want to take this on in steps that are repeatable and consistent which is the goal of any automation: consistency of outcome that allows you to speed up the velocity of deployment, safely.

Start with Bad Ideas which Become Good Practices

You’re very literally getting some bad practices in this code set because we want to show the progression from doing things manually to making the jump to efficient, codified infrastructure-as-code.

What this repository will do that is not the best idea is to literally map out the code for each VM clone as standalone code blocks. Then the part 4 of the series will show you how to DRY (Don’t Repeat Yourself) up that code. What I always dread as a blog reader is when the new methods are so rapidly introduced that it doesn’t give you a chance to see how the machine is made. That’s where I hope you’re finding this progressive blog series style helpful.

Any file you create in the folder with a .tf extension will be evaluated by Terraform as part of the provisioning. You can create these as a large single file, or separate logical files depending on your preference. I prefer to do a separate file for logical groupings of infrastructure. We won’t get into Modules yet…save that for the next blog series!

Building the Three Application VMs

You will be using a single basic template across all of these clustered nodes which makes it easy. Then we can move the goal post a bit further and add in the app deployments as we close out the series.

Let’s use a single file to describe all three of our application VMs. This file we will reference here is the app-vms.tf file located here in the GitHub repository.

Our new code will include three resources, each coded with the name of the VM to make them unique. The uniqueness is needed or else Terraform will complain of duplicate resources. In our first blog we only used the name “vm” whereas this will use “vm-app-1”, “vm-app-2”, and “vm-app-3” for both the app-vms.tf file and the outputs.tf file.

Example apps-vms.tf:

The outputs generated by the Terraform configuration in our outputs.tf are also explicitly set by the machine names.

Example outputs.tf:

There is repetitive code that we will remove as part of the part 4 of the blog series next. Typing terraform output renders the IPv4 and IPv6 addresses which are picked up by the VMs as they launch.

Next up is the two database clusters which are 3 virtual machines to each cluster.

Building the SQL 3-Node Cluster VMs

This file we will reference for our SQL cluster is the sql-3-node.tf file located here in the GitHub repository. We are using the same simple template just to illustrate the cloning process. The next blog will show how to run inline command and remote commands to complete some install scripts for the applications.

That takes care of three app servers and three SQL servers to prepare for the MariaDB cluster. Last step is our future requirement of a NoSQL environment. This is an advantage of doing IaC because we can do a lot of heavy lifting easily in code. Yay!

Building the MongoDB 3-Node Cluster VMs

The final part of our multi-VM deployment is our MongoDB servers. The file we will reference for the NoSQL cluster configuration is the mongo-3-node.tf file located here in the GitHub repository.

The same will go for our actually MongoDB install which will be done with some easy scripts that we have in the next blog.

Just like that we now have 9 servers which can be torn down and redeployed just by typing terraform destroy and then a terraform apply again to clone a new set.

You can also see the final outputs file with all 9 output stanzas together here.

What Have We Learned and What’s Next?

Now you know how to expand your deployment with multiple virtual machines using the Terraform configuration files. What you’ve learned here is that:

  1. Every file ending with .tf will be evaluated and provisioned by Terraform
  2. You can use one or more .tf files – multiple files can be easier to organize by groups of VMs
  3. Repetitive code creates work but seems simple at first – welcome to technical debt
  4. Codifying at the outset means we can easily add components on the fly

The next step is to bring in some simple loops to remove repetitive code and to tighten up our scripts a bit. This won’t change the output at all but will simplify how much code we have. This will prove to be helpful when we go beyond just 3 machines in the cluster. Every step makes your IaC chops more versatile!

Read More

IaC Powering a Monolith to Multi-VM Architecture – Part 2

Posted by Eric Wright on Jun 4, 2020 2:57:44 PM

Our first post in the series introduced the scenario where our IT teams on the Cloud Rush application had an application needing to make its way to production. This is often the case where the Ops team is handed the working version and asked to work backwards. It’s also important that the reason this happens is that development teams often feel like they have to do a lot on their own to get products built faster. This is our chance to bring those two teams together and use the power of good IT architecture and Infrastructure-as-Code to ensure both speed and consistency of outcome.

Read More

Infrastructure-as-Code Powering a Monolith to Multi-VM Architecture – Part 1

Posted by Eric Wright on Apr 17, 2020 3:36:53 PM

There are many questions in the air when it comes to architecting your application for a cloud or virtual environment. Designing with a systems thinking approach means that we want to look at our requirements, constraints, assumptions, and risks. The best way to do this is to look at a specific scenario played out which is what we are going to here in the first of our Couch to Cloud Native (C2CN) series.

Read More

The Power of Automation on IT Career Advancement

Posted by Eric Wright on Jan 8, 2020 3:08:00 PM

We all know the headline that will read “automation is taking away jobs”. What we have to see beyond the headline is that it’s a good thing. It doesn’t take long to realize the benefits you can gain if you take a few moments each day and track the repetitive and relatively mundane tasks we do.

Automation is much more than just the mundane and repetitive stuff. The goal of automation is about increasing the flow (and value) of your work. What makes automation successful are five very key features:

Read More

What is Infrastructure as Code and What Does It Mean to You?

Posted by Eric Wright on Jan 6, 2020 11:15:00 AM

The world of IT Operations has been changing in many ways over the past few years. The rise of public cloud created an urgency for traditional operations teams to adapt their own systems and processes to either embrace a public cloud infrastructure, or to create a more cloud-like experience with their internal infrastructure to keep pace.

Public cloud is on a rocket rise in adoption but will not unseat every data center regardless of the rate of adoption. Many data centers are moving towards managed colocation and on-demand providers, mostly because it opens the door for more programmatic approaches to building and managing infrastructure and removes the overhead of managing environment (e.g. power, cooling).

Infrastructure-as-Code, or IaC, has become one of the most dominant features which allows for the accelerated and more consistent management of on-premises or public cloud infrastructure.

Read More

Reserving Your Good Storage: Why You Shouldn't Do It

Posted by Eric Wright on Jan 2, 2020 12:27:00 PM

If you’re like me, you probably had, or know someone who had a house with a room that nobody was allowed to go into except for “special occasions”. The furniture was often covered in plastic, and the carpet was impeccably clean, vacuumed weekly despite nobody walking on it except the person using the vacuum.

Read More

What is Vendor Lock-In?

Posted by Eric Wright on Dec 18, 2019 11:30:00 AM

There is an ongoing discussion (read:argument) around something that is like the Voldemort of technology: vendor lock-in.

Read More

Why People are Moving Towards Microservices

Posted by Eric Wright on Dec 11, 2019 11:00:00 AM

Let me start by giving my one line view of the reason for the uprising in awareness of microservices, containers, SDN and the ever-present SDDC (Software-Defined Data Center): This is about agility, not speed.

Read More

Subscribe Here!

Recent Posts