Agile Articles

Configuration Management – Just Do It!

Configuration Management, as applied in DevOps, is the practice of using tools to manage the configuration of our technical architecture.  Put simply, we document the desired state of one or more servers in a machine-readable form, and then use a configuration management tool (e.g. Chef, Puppet, Salt, or Ansible) to setup the real items to match the configuration.

Why?  As with many things, you might think “I barely have time to setup this server manually, never mind write a script for it”.  But the reality is, in today’s world, we’re probably going to have to do the same setup multiple times.  In enterprise environments, the software engineering process will require deployment to several environments (development, integration test, user acceptance test, performance test, then finally production).  It’s critical that all these environments are identical (so far as is practical).  This is a key tenet of DevOps operating practices – we can’t apply learnings from one environment to others if the environments are different.  Even in a simpler environment, you’re probably going to replace your servers in a fairly short time frame.

Once upon a time, we used to buy server hardware and nurse it along for years.  Nowadays, hardware and system software ends up obsolete in a matter of months, not years.  If you’ve done your CM work properly, it’s faster to deploy to a fresh OS image than to patch an existing image.  And if you’ve embraced virtualization or a cloud environment, you’ll find it’s easier to replace a server than to troubleshoot it.

There’s another advantage to Configuration Management:  The system state is documented and version controlled.  There’s no need to do archaeological work to find out what your technical architecture has evolved to – you just look at the configuration scripts.

So here’s your challenge for the next year: Stop managing your servers by hand.  Setup an open-source Configuration Management system and create a configuration repository (I’m partial to Ansible.  See http://www.webagesolutions.com/knowledgebase/kb024/kb024-install-sw-ansible.html for some tips to get started).  Every time you find yourself ssh-ing or logging in to a server, stop yourself and create a playbook, recipe, or run-list in your CM repository.   Make it a habit to use manual tools only to examine the server state, not to change anything.  Run your servers the way developers write code:  If it isn’t in version control, it didn’t happen!

For that matter, do the same thing on your laptop or workstation.  You’ll soon find that you’re much less stressed about maintaining your configuration or upgrading your hardware.

No Comments

Provisioning Tomcat with the Amazon EC2 Service

In this blog article, I will walk you through the steps required to quickly provision an instance of the Tomcat web server in the Amazone EC2 service. When Tomcat is up and running in EC2, you can upload your WAR (Web ARchive) file that gets automatically deployed and made available for processing HTTP requests from the Internet.

My assumption is that you have an account with Amazon Web Services (AWS) which includes the EC2 service and you have a WAR file that you want to deploy in the cloud.
Read the rest of this entry »

No Comments

Linux Containers

What are Linux Containers

LinuX Containers (LXC) is an OS-level virtualization that allows multiple Linux systems to run on a single physical machine in a multi-tenant arrangement. This type of virtualization is extremely lightweight with every virtual machine (container) being mapped into the booted host OS obviating the need to boot from their own OS image; all the needed resources of the host machine — CPU, the filesystem, system libraries, network access, etc. — are received by containers on a shared basis. Basically, LXC re-uses the same single kernel of the host machine for all hosted containers.
Read the rest of this entry »

No Comments

Standing Up DevOps

While originally DevOps was popularized by Web (Cloud) -based companies, such as Flickr and Netflix, large enterprises, in one form or another, have long been using select DevOps practices.

For deeper penetration of DevOps in the Enterprise space and establishing it as a true enterprise capability, it needs to be placed under control within the existing enterprise governance processes.

For sure, there is no cast-in-stone rules on how to set up the DevOps capability and every organization finds its own organizational form for DevOps. For example,
Read the rest of this entry »

No Comments

DevOps in a Nutshell

DevOps is nowadays a big thing and in this post we will try to explain what this practice is in practical terms.

The term DevOps is rather limiting, indicating that only Development and Operations are involved, which is not absolutely true (as is always the case in this life) — DevOps is not only about Development and Operations!

If you wish, you can view DevOps as

  • a culture, or
  • a cross-team software delivery discipline (paradigm)

In essence, DevOps tries to reconcile the clashing cultures and views on software delivery of Development and Operations that are summarized in the table below.
Read the rest of this entry »

No Comments

Architects – do you know if your team members are embracing your work?

Architects can generate volumes of documentation and models, but who reads them? They can even model these things in tools, but does this ensure the architecture is followed?

My experience is in any project – large or small – you can usually tell if the architecture has become a shared vision by looking at the members’ work spaces to see what they have pinned to the walls. Or the one-pagers they bring to meetings. People will post helpful things in their cube:

• A picture of the reference model/conceptual model – a picture of the shared vision
• A picture showing a typical collaboration of the solution components:

Typical Solution Component Collaboration

• A picture showing the architecture dependencies between the major subsystems which teams are usually formed around.

Solution Component Build Dependencies

Solution Component Build Dependencies

• A picture (i.e. collaboration diagram) depicting a key design pattern meaningful to their work
• A checklist of items to consider before submitting code for the nightly build or sprint
• A high-level diagram that illustrates the flow of artifacts to coordinate a sprint/increment

Configuration Management Centric Development Flow

Configuration Management Centric Development Flow

• A high-level diagram that illustrates how all the key processes relate to each other

Enterprise Modeling to Sprint and Release

Enterprise Modeling to Sprint and Release

If isn’t pinned to their cube it is handy and people will bring them to meetings.

Solution implementation is a fluid thing and these diagrams must evolve. This is performed by a regular architecture/team lead “stand up” meeting. Not stand-up because people have to stand up, but because people are there to discuss items that matter. They are busy and focused on being productive. All subsystem/stream leads are focused on sharing critical items and gaining consensus that will move their team forward.

The facilitator is the lead architect – not because they know more, but because they are a good facilitator and believes a better architecture is made from ensuring the best ideas are leveraged no matter the source. The lead architect (or technical manager or scrum master) does have to have a breadth of knowledge to be able to understand all the topics discussed and ask questions to help the team come to a decision.
The meeting doesn’t talk about status, schedule, or resources. It focuses on the product and topics like:
• Points of integration
• Dependencies
• Alternatives and recommendations to leverage the experience of others
• Shared services
• Recommended patterns, practices, and standards
• Technical issues to be researched and reported on at the next meeting

The meeting can be managed by using many different techniques:
1. When items come up that involve a subset of people, quickly identify the stakeholders and assign a working group to bring a recommendation back
2. If not enough information is available, assign someone to research the additional information
3. If a knowledge gap is apparent, the action item may be for the lead architect to schedule training
4. If the problem appears to be a vendor product issue, the technical person responsible for that vendor relationship takes the action item

Whether you call the facilitator the lead architect, technical manager, scrum master, or servant leader, they are the “glue” of the product and process for the design and build teams.
At the end of the productive meeting, the lead will update:
• The Action Item Log
• The Decision Log
• The Risk Log

Also the lead architect will reflect on additional action items that may be helpful to the team:
• One-on-one discussions to further refine the problem or educate members
• Additional formal training
• Engaging management with the vendor to gain better response time
• Additional tools (e.g. automation scripts) to help the team
• New or revised patterns
• Demos from a team that will help solidify the vision and encourage the team
• Informal sessions from a team member that performs really well on a technique that other people are struggling with

This person, the “glue” is many times invisible and behind the scenes helping the team leads/scrum masters of a team to be successful. They work with management behind the scenes to buffer the team from “necessary but evil” overhead. They encourage team leads when they are frustrated because they have been in that situation before and can empathize. The invisible super glue 🙂

1 Comment