Justin Nemmers
Author Archives: Justin Nemmers
- Home → Author's archive:
Justin Nemmers
IT Automation is in the Spotlight at AWS Re:Invent (and OpsWorks Configuration Management is Just Part of the Story)
Configuration management is just the start
Automation is getting a lot of attention at AWS:ReInvent this year, as people are noticing that automation is drastically accelerating the pace of innovation within IT organizations. Whether they’re part of a DevOps initiative, attempting to modernize their existing processes, or migrating systems and applications to the cloud, infrastructure-as-code style automation is playing an increasingly bigger part in these efforts - and ‘configuration management’ is getting most of the attention.
In a recent study, IDC’s Melinda-Carol Ballou predicts that the configuration management portion of I&O spending will grow at 8% over the next several years… but the predicted growth of configuration management in public clouds is north of 31%. Similarly, in a separate report, Mary Johnston Turner and David Laing forecast the Automation component of Infrastructure spending in the public cloud to grow at almost 35% - compared to just 12% overall.
The trend is clear: configuration management is seen as critical to cloud adoption and migration. So it’s not surprising that Amazon Web Services announced that it is updating its Opsworks service offering. As environments grow in size, scope, and complexity (which is the new normal in the era of the cloud), the Continue reading
Automating a Multi-Platform World
Just because your organization has a multi-OS strategy should not automatically increase the complexity of your environment management. Each OS vendor likely drags along its own ecosystem of partners, development platforms, support and capability matrixes, and for the most part, once a system is developed on a particular OS platform, it tends to stay there.
Enter cloud. With growing abstraction of the infrastructure layer, cloud has done a great job of providing enterprise IT organizations with a level of control and flexibility once only available to the most advanced of greenfield deployments.
Even in a cloud-deployed environment, there is still a lot of potential baggage based on your particular cloud vendor, let alone your entire development suite and application platform. In nearly all cases, once an app is written for a particular platform, it stays on that platform for the entirety of its lifecycle. If your primary cloud vendor doesn’t provide you an easy way to deploy-- in a supported manner-- your preferred application platform, customers face yet another area of complexity. Just like that, you could be stuck with few choices.
This is precisely why the joint Red Hat/Microsoft announcement today is a huge win for customers, and further Continue reading
AWS re:Invent re:cap
What a week. Some tech conferences I like, and others I love. Falling solidly in my "love" category, the Amazon team pulled off another great event with re:Invent 2015. Of course, the AWS product folks didn’t disappoint, either. (And neither did surprise re:Play party guest Zedd.)
We welcomed many hundreds of visitors to our booth during the three days. Over 200 shirts, many more Ansibulls, and every single sticker, luggage tag, and business card were gobbled up by excited Ansible users and Tower customers.
Perhaps the most entertaining part was to learn what people had to say:
“We heart Ansible.”
“Ansible is the only predictable thing about our environment.”
“DevOps? More like AnsibleOps.”
“You guys changed our lives.”
“I keep getting told I need to look at Ansible.”
“Thank you… just thank you.” (My personal favorite)
Certainly all bold statements for an IT orchestration tool. Even Network World joined in on the fun by naming Ansible one of the hottest products at re:Invent, thanks in part to our new IAM modules that simplify the setup and maintenance of IAM users, groups, keys, and policies.
The sentiments got me thinking. Seemingly, AWS is Continue reading
Ansible + AWS: Re-Inventing Cloud Automation
Amazon Web Services and Ansible together make a great pair. AWS is a popular cloud target for Ansible users, and the reasons are clear: Ansible offers built-in support for over 20 different AWS capabilities with 50 different easy-to-use and understand Ansible modules. And as always, from on-premise to cloud, you can automate 100% of your infrastructure without ever installing an agent.
The takeaway? If your IT organizations is serious about AWS, then it needs to be serious about Ansible automation.
Come visit Ansible in booth 439 at re:Invent 2015 to learn how customers are using the Ansible automation platform to re-invent how they’re managing their cloud applications. Whether you’re just dipping your toe into the cloud, or are already running a fully-automated devops-enabled environment, Ansible is the key to unlocking the full benefit of moving to the cloud.
Connect with our team at the show:
|
|
Todd Barr
|
|
|
Justin Nemmers
|
|
|
John Ryan
|
|
|
Dave Johnson
|
|
|
Danny Ganzon
|
|
|
Jonathan Davila
|
If you’re new to Ansible, this is your opportunity to hit us with whatever questions you have about how Continue reading
Ansible + AWS, Red Hat Enterprise Linux, and JBOSS
Many of the questions we frequently get are related to deploying applications and stacks into Amazon Web Services. Back in July, Ansible Government teamed up with partner DLT Solutions to host a webcast demonstrating the creation of a Red Hat stack in AWS entirely managed with Ansible. Watch it now and continue reading below for more information.
IT organizations look toward AWS for a number of reasons, but according to IDC, deploying applications in AWS results in a 64% lower TCO and 82% less downtime. Now let’s be honest. Who doesn’t like less downtime?
Red Hat is the leading Open Source provider for infrastructure and middleware solutions. Their industry-standard Red Hat Enterprise Linux and JBoss middleware are widely deployed in on-prem physical and virtual environments, and are the benchmark for stability, security, and performance.
But how can you leverage that power in AWS? With Ansible, it’s easy.
In the webcast, we demonstrate the deployment of a complete JAVA-based web application, including RHEL, JBOSS, and a load balancer. Once installed, we demonstrated how to use the same playbook that deployed the application to update the application. Better yet, these examples are available for you to start using and experimenting with today.
Here’s Continue reading
How To Do DevOps Without Leaving Legacy Behind
An increasingly apparent and large challenge in IT organizations is how teams can effectively modernize software development and IT operations while still operating and maintaining legacy infrastructure. Often the approach is to merely draw a line in the sand, creating an arbitrary cut-off whereby new implementations make use of the much desired DevOps and Agile methodology.
But what about the legacy environments?
Just because something is “legacy” doesn’t automatically mean that it’s twenty years old. Many so-called legacy systems were deployed mere months ago-- and on modern hardware, operating systems, and storage. For the sake of an agile organization, however, a legacy deployment or environment is anything that is not included in the new processes and approaches required for a DevOps-enabled organization.
The question remains: how can IT organizations successfully apply DevOps and Agile methodologies to existing legacy environments, and what are the benefits from doing this?
Start with the Infrastructure
Regardless of the type and variety of applications in an enterprise IT environment, there are likely many commonalities in the operating system and infrastructure components.
Manual OS build processes typically require significant admin-hours to deliver a single build. Additionally, the reliability of the result is a totally dependent Continue reading
The Ansible Basics: Why Automation Matters Today in IT
Your development team has completed weeks of work, delivering their masterpiece-an application-to IT for deployment, but it doesn’t work.
See, the developers made use of a different port, that now needs to be opened on the firewall so end users can communicate with the software. IT changed the firewall rule, but didn’t tell development, so they never even knew it was an issue. Later, they create another application with the same issue, except this time, it will be deployed in a different environment.
No procedure or policy was created to capture all of the changes necessary to successfully deploy the app, so the same thing happens again. It’s a vicious cycle.
IT departments struggle to manage thousands of configurations and hundreds of applications with everyone working in silos. Teams who develop the apps frequently are not on the teams that use them. Meanwhile, operations teams deploy apps they didn’t write and have to convey to the development team when changes need to be made in order for them to work in this new and foreign-to-development thing called "a production environment".
Sound familiar?
Today’s IT environments are extremely complex. In the past, applications and hardware were closely connected. Apps came from Continue reading
Work Smarter, Not Harder with Security Baseline Configuration Automation
Many security baseline processes are rife with challenges. Whether organizations use scripts to manually brute-force their system-level compliance baseline, or perhaps leverage the all-too-common “Gold Disk” approach, routine security baseline compliance remediation remains largely an unsolved and constant challenge even for the most mature of IT organizations.
Even for organizations that are using an existing management tool to help with their security baselining, issues frequently arise around how to identify systems that require baselining as they come online, and then immediately recognize what needs to be done on those systems in order to verify their compliance.
To add to the challenge, applying a baseline to a newly deployed server or application is one thing, but validating compliance throughout the server and application lifecycle typically requires a separate set of tools or processes, or at very least scripts that are smart enough to smartly change the existing state of a server or application without impacting its availability.
MindPoint Group knew there was a better way. The security folks at MindPoint group are leveraging the power and simplicity of Ansible to bring automation to the problem of security baselines. And thanks to Ansible’s design, the work that MindPoint group has done is Continue reading
Making STIG Automation Possible: A Technical Deep Dive
Ansible architect and craft beer connoisseur Jonathan Davila played a critical role in working with our trusted security partner MindPoint Group to get our joint automated security baseline project off the ground. With our release this week of the DISA STIG for RHEL 6, we’ve immediately improved the lives of Government IT admins that struggle to ensure their systems are compliant.
Merely building the Ansible role for Red Hat Enterprise Linux 6 (And CentOS variants) STIG required more than writing and organizing a collection of playbooks. In order to ensure that the role actually achieved the remediation goal, we needed to validate and verify updates through a continuous integration testing process that leverages the DISA-provided SCAP/OVAL definitions.
You can learn more about the mechanics of how Jonathan and the MindPoint Group built the STIG Role, along with technical details about how to replicate this testing method in your own environment here.
Want to learn more about the how and why? Jonathan also penned a LinkedIn article with his own thoughts about why this is an important step in the right direction for any IT organization that’s concerned about automagically applying and validating security baselines.
Learn more about automated baseline testing.
Continue reading
Ansible and MindPoint Group Deliver Automation for Government STIG Compliance
Ansible has teamed with security consultancy MindPoint Group to develop, release, and support a set of Ansible Roles that will save IT organizations considerable amounts of time when applying and maintaining security baselines such as the DISA STIG or CIS benchmark to IT environments.
Why MindPoint Group? That answer is simple. MindPoint Group has a singular focus which has led to an excellent reputation for delivering end-to-end security solutions to commercial and government clients alike. This focus, coupled with their love of Ansible, made MindPoint Group a natural choice for partnering on the development of free-and-open security baseline roles and playbooks.
The best part? This relationship is already helping Ansible users.
The first Role is for the DISA STIG on RHEL 6 (and variant systems) and is now available in Ansible Galaxy. This Role enables customers to automate the application and management of STIG-compliant systems in their environments, all the while leveraging Ansible’s agentless management framework. When applied using Ansible, the RHEL 6 STIG Role automates a significant amount of the manual and redundant scripting and remediation that IT organizations often rely on to ensure they meet the STIG OS requirements.
Releasing this important Role is just the beginning. Continue reading
5 Reasons to Use Ansible in Government
As many US Government programs look to adopt DevOps and agile development methodologies, there’s a need for tools to manage the application lifecycle, and make it easier and more predictable to deploy and manage entire application environments.
So why do Government customers chose Ansible?
Agentless
Ansible does not require a software agent to be running on the remote hosts it manages. Instead, it relies on the trusted management ports you’re already using on a daily basis to log into your servers: secure shell (SSH) on Linux, and Windows Remote Management (WinRM) on Microsoft-based systems. This means that you don’t need to change existing firewall port filtering rules, which removes a large barrier to entry that other tools that run an agent require.
Additionally, agentless management means that there is little likelihood of a library conflict. What happens when a management tool agent requires one version of a library, but your application requires another?
Finally, Ansible’s agentless model does not increase your system’s security footprint or attack profile. Ansible relies on the operating system’s encryption tooling, and ensures that there are no separate agents that require vulnerability patching.
More Than Just CM
Configuration Management in the Government space is nothing new. Continue reading