As your IT infrastructure grows, it becomes increasingly important to be able to identify where bottlenecks, performance problems, or outages are occurring so that you can quickly act to fix any issues. Identifying the source of a problem can be a bit tricky once you have grown into having multiple apps, servers, and databases—but there are tools that can significantly ease your burden in locating where an issue has arisen.
Often, IT infrastructure begins on a small scale. Perhaps you start with a single app that runs on a single server with one small database. At this point, it is usually fairly easy to determine if that server is down, since everything will simply stop working. If it is simply the database itself, the app will most likely return errors connecting to the database.
At this level, you likely won’t feel any urgent need to set up a more robust form of monitoring. After all, there are only so many things that can go wrong. However, as your services grow, managing those services in an efficient manner becomes increasingly important.
Once you begin having multiple apps, servers, or databases, you will find that keeping track of issues becomes more time-consuming and difficult, since it may not always be clear what part of the system is failing. For example, if you have two apps using the same database server and both are not responsive, you will need to determine whether both app servers are down or the single database server is down. This could require checking in several different places to ensure you identify the correct cause.
The Solution: Using a Monitoring Service to Manage Your Services
A monitoring service can quickly show you if you have any problems. Source: http://www.happyapps.io
Time to resolution is important when diagnosing and fixing any downtime for your services. You can save yourself quite a bit of time by having your various services monitored. A monitoring service cannot only send you alerts when things go wrong, but can specify which service is misbehaving or down.
For instance, if your database server has crashed for some reason, you are alerted immediately and know exactly where to go to fix the issue. If you have multiple database servers, this is even more valuable, since you will know which one it is without looking at each server until you find the one that is in error.
With a monitoring service like Happy Apps, you also get to tailor the alerts to suit your needs most effectively. You can choose to have notifications arrive by e-mail, text messages, or push notifications to your mobile device. You can also limit your alerts if needed, so that you receive only messages when there is a critical issue as opposed to something being temporarily slower than normal. Incidents are automatically opened whenever a check fails, and once all checks in an incident are passing, the incident will automatically become closed. You can always drill down to a specific incident and view the details (i.e. issues, history, and members), and Happy Apps tracks your incidents so you can understand how you fixed previous problems if the incident were to arise again.
So, why not setup your services with Happy Apps? The configuration process, often a time-consuming challenge, is made incredibly easy with Happy Apps: with just a few clicks and less than 60 seconds Happy Apps checks are watching your services. Furthermore, in DevOps style, there is an API to add checks as well. The time you save yourself in identifying where problems are occurring will make you and your end users happy!
***This post is based on themes and ideas from the great e-book, “Continuous Testing,” by our friends at Parasoft.
The aptly named DevOps practice of Continuous Testing synchronizes Testing/QA with Dev and Ops processes optimized to achieve business and development goals.
A few years ago when Agile was all the rage, lightning-fast Dev sprints left the Ops and QA personnel playing catch-up due to inadequate and sluggish testing practices with minimal coverage across frequent builds.
The widespread culture of Agile development has accelerated development while software testing still lags behind, forcing organizations to cut corners in QA or slow down Dev processes entirely.
Instead of speeding up the conveyor belt beyond control or slowing down development to kill efficiencies, Continuous Testing in DevOps encourages a systematic approach toward process improvement.
Continuous Testing goes beyond automation and encompasses all practices — including tooling and cultural change — that help mitigate risks before progressing to subsequent Software Development Lifecycle stages.
Continuous testing and Automation
The approach to Continuous Testing can vary and follow diverse pathways to ensure the best user experience is delivered, free of defects.
It’s barely viable to repeat all tests every time a new feature is added, so the Continuous Testing strategy fosters a company-wide cultural change to achieve four capabilities: Test early, test faster, test often and automate.
End-to-end test automation practices are intended to integrate QA into existing fast-paced Dev and Ops processes as a means to create continuity while maintaining faster development cycles.
It’s important to understand the role of automation in Continuous Testing. Automation alone does not enable continuity in testing, but it helps provide a qualitative assessment of risk and practice actionable tasks to mitigate these risks throughout the SDLC.
In essence, automated testing constitutes the detection process for software issues and defect prevention, whereas Continuous Testing addresses the wider challenge of improving the effectiveness of these detection sensors.
What does Continuous Testing Look Like
This example demonstrates how collaboration, automation and tooling enable end-to-end testing that’s performed faster, more often and better aligned with Agile Dev and Ops practices.
Continuous Testing starts within development processes as Devs use open source tools such as Selenium to test the functionality of their code.
Tools such as GitHub or other internal repositories can then be used to store tests and version together with the software code. DevOps teams can use the same tests to integrate frequent builds of the software with the Load Impact API.
Once the code reaches preproduction, dedicated QA teams can use these tests by modifying dynamic test parameters as appropriate. In the production environment, Ops can reuse these tests for acceptance testing and ongoing post production monitoring.
Once the application goes live, integration with existing APM tools help keep tabs on server-side app metrics.
Continuous Testing in this example is broken up into at least four environments: Development environment, Continuous Integration environment, QA Pre-production and Performance testing environment, and the Staging environment. Additional post-live monitoring further enable end-to-end continuous testing.
Key Elements of Continuous Testing
Parasoft, a global software solutions company, is one of the great thought leaders in DevOps and Continuous Testing. The company has laid out some key elements of the process in a fantastic e-book, and they’re definitely worth sharing here:
Risk Assessment: Covers risk mitigation tasks, technical debt, quality assessment and test coverage optimization to ensure the build is ready to progress toward next SDLC stage.
Policy Analysis: Ensure all processes align with the organization’s evolving business and compliance demands. Primary objectives include:
Identifying trends associated with injection of dangerous patterns within the code
Augmenting defect prevention practices for high risk areas
Isolating risk in target areas
Requirements Traceability: Ensure true requirements are met and rework is not required. An object assessment to identify which requirements are at risk, working as expected or require further validation.
Advanced Analysis: Using automation in areas such as static code analysis, change impact analysis and scope assessment/prioritization to prevent defects in the first place and accomplishing more within each iteration.
Test Optimization: Ensure tests yield accurate outcomes and provide actionable findings. Aspects include Test Data Management, Test Optimization Management and Test Maintenance.
Service Virtualization: Early, frequent and everywhere testing requires access to real-world testing environments. Service visualization enables access to the virtual form of the required testing stages, cutting the waste time to test environment setup and availability.
An effective Continuous Testing strategy incorporates all of these elements and forces an organization-wide cultural change to synchronize Dev, Ops and QA/Testing as part of the true DevOps philosophy.
It’s a fast-paced world. Recent research from Microsoft suggests that the attention span of the average human is about 8 seconds now. That means if your application doesn’t work as expected your users will quickly move on to find a suitable replacement. An application performance management tool can be crucial to identifying and resolving application issues as quickly as possible…while you still have the user’s attention.
Stackify introduced APM+ to give .NET developers real-time application performance analysis. Stackify has already established itself as one of the leading vendors of application performance management. Its platform monitors important metrics like CPU, memory, and disk utilization on servers and alerts developers or admins when issues arise. Now it is extending that monitoring to Microsoft ASP.NET environments with APM+.
“The level of real-time app performance and depth of APM+ analytics is unmatched in the market. Not only does Stackify give a complete 360-degree view of how a system is spending its time and where, but it also allows developers to quickly drill down to the heart of the code and see how it can be fixed or improved,” says Stackify CTO, Jason Taylor.
Application performance management in general, and a tool like APM+ specifically, fit neatly with the principles of DevOps. As I noted in a previous article DevOps is “continuous” at virtually every level. There is no beginning or end—no point when an application is completed and deployed and you can kick back and relax. While finishing touches are being put on an app to prepare for a new release a laundry list of changes and updates is already being worked on to develop the next release. There’s no rest for the weary (developers).
There will always be fixes and new features to work on for an app, but application performance management gives you insight into the changes that matter most. Knowing things like which app takes the longest time to load, or which app gets called the most often, or which app is failing the most gives developers a huge advantage that allows them to devote resources where they will have the most impact.
According to a Stackify press release, “APM+ gives developers an increased understanding at every level of an application’s performance and offers code-level profile traces to provide unparalleled system visibility — including method calls, log statements, cache lookups, DB queries, and web service requests.”
Why is that important? A couple reasons stand out. First, you want to be proactive about identifying and resolving issues with your apps. The old-fashioned method of waiting for users to report problems is too slow and reactionary. By that point you already have disgruntled users frustrated with your app.
The second major reason is that a tool like APM+ gives you a streamlined ability to resolve the issue(s) plaguing the app. Rather than a user reporting a problem and developers poking and prodding to investigate what the underlying issue is, APM+ gives developers visibility into metrics and data that enable them to quickly find and fix the problem.
APM+ is focused on the .NET framework initially but Stackify notes that it plans to offer support for a broader range of development languages later this year.
If that sounds vaguely like UDDI (which dealt with discovery and search of WSDL then you’re on the right track.
Glue is this week, and preceding the conference was the 2015 API Strategy and Practice Tech Un-Workshops. One of the lightning talks (and they were lightning fast, let me tell you) was all about APIs.JSON – a relatively new collaborative effort between Kin Lane, API Evangelist, and Steven Willmott and Nicolas Grenie of 3scale networks,
The effort – which you can dig into at apisjson.org – is an attempt to provide a more formal and standardized definition of APIs designed for “public deployment and consumption by automated software agents (robots)”. In a nutshell, automated agents (and people, too, if you like reading machine-consumable metadata) can access a meta description of the APIs available for an organization at a known (standardized) URI such as http://company.com/apis.json.
It’s not quite a WSDL for JSON, as the metadata is not describing the actual interfaces, but more like UDDI entry that might have once (and maybe still is) hosted in a registry (repository). The current incarnation provides basic information about the APIs and includes basic properties like a name and descriptions and URLs and can also contain more (some might say usable) information such as links to documentation or an actual, real-life readable API definition such as Swagger or API Blueprint formats as well as WADL and WSDL.
The effort is showcased in an open API search engine (http://apis.io) that allows individuals to seek out APIs (over 900 are listed today) based on a variety of criteria, all of which of course is derived from the metadata within an APIs.JSON file.
What does this all have to do with DevOps? Well, as Steve Willmott astutely pointed out in his lightning talk, APIs.JSON is not just about describing APIs in a consumable format, but it’s about being able to have machines discover and bootstrap APIs. That means potentially being able to trigger and signal changes about an API to kickstart a new build and deployment process.
This is a great example of the possibilities for collaboration between Dev and Ops when everything is treated like code and automation moves from simple tasks to workflows – to orchestration.
And I probably don’t have to mention (but I will, because , me) that the same trigger and signaling process could (and probably will) hook into broader network infrastructure (the components that exhibit high application affinity like load balancing and caching and app security) to drive more automated change management.
APIs.JSON is not the first (and won’t be the last) effort of this kind because the mobile and app economy of the future is being built on APIs and thus , as Steve Willmott stated in his talk, “the Web of APIs is the future of the web.”
Ansible is an IT automation engine, and a trouble-free model-driven configuration management and command execution framework. Made for multi-tier deployments, it designs your IT infrastructure by describing how all of your systems are interrelated instead of just managing one system at a time. Written in Python, Ansible does not use any agent. It makes uses the SSH server on the target, and no additional custom security infrastructure is required, making it easy to deploy.
Ansible comes up with following uses:
1). Normal configuration management
Creates system files through the medium of templates
Manages software installation with the help of yum, apt, gem, or the like
Manages services or daemons such as start, stop, enable, disable
2). Orchestration tasks
Removing server from load balancers
Disabling monitoring or altering
Perform deployment of your code by git
3). Continuous integration
Deploy code to QA servers
Run tests and promote software to production if tests pass
How is it different?
Ansible is a configuration management, deployment and an ad-hoc task execution tool, all in one. It does not require daemons or any other software to start the remote machines’ management. Since it uses the SSH, it easily passes a security audit, and can be used in places resistant to run a root-level daemon with a custom PKI infrastructure.
The Ansible modules can be written not only in Ruby or Python, but in any language efficient enough of returning JSON or key. In this way, Ansible manages to sidestep the popular Python vs Ruby language war, and is of interest to people who like both or neither of them.
Ansible Architecture:
Coming with a simple framework, Ansible connects with your nodes and pushes out small program termed as Ansible Modules, which are considered to be the workhorse of the system and are responsible for performing all heavy liftings. These programs are written to be resource models of the anticipated position of the system. Thereafter, Ansible carries out these modules upon the SSH by default and eliminate them when finished.
Without using servers, daemons and databases, your library related to modules can be inherited in any machine, thus giving the advantage of working with your favorite terminal program, a text editor, and most likely a version control system to keep a track of alteration to your content.
SSH keys your biggest companion
Though passwords are supported, the finest method to practice it is by using the SSH keys along with SSH-agent. The root logins are not required; you can login as any user. Ansible ‘authorised-key’ module helps in controlling which machines can access or which hosts. You can also use other available options like Kerberos or identity management systems.
Management of your inventory in simple text files
Ansible by default uses an INI file to represent the machines being managed. These files help in placing all of your managed machines in groups of your own choosing. In order to add up new machines, you do not require any additional SSL signing server. So by no means, there will be a problem in deciding about why a particular machine didn’t get linked up due to obscure NTP or DNS issues.
Ansible can also be plugged into another source of truth, if available in your infrastructure like drawing inventory, group, and sources suchlike EC2, Rackspace, OpenStack, etc,. As soon as the inventory hosts are listed, variables can be assigned to them in simple text files in a subdirectory called ‘group_vars/’ or ‘host_vars/’ or directly in the inventory file or, as already mentioned, you can use the dynamic inventory to pull inventory from the data sources like EC2, Rackspace, and OpenStack.
Playbooks, a simple and powerful automation language
Playbooks are Ansible’s configuration, deployment and orchestration language. They can explain a course of action you want the remote system to apply, or a set of steps in a general IT process.
At a fundamental stage, playbooks can be used to manage configurations and for deployments of the remote machines. At a more advanced level, they can sequence multi-tier rollouts involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way. Most importantly, the language remains readable, transparent and is developed in a basic text language. You don’t need to declare explicit ordering relationships or write code in a programming language. There are ample of ways to organise playbooks and the files they include.
Widen up Ansible: Modules, Plugins and API
Ansible modules can be written in any language that can return JSON, such as Ruby, Python, Bash, etc,. The inventory can also plug into any data source by writing a programme that speaks to that data source and returns JSON. There are multiple Python APIs for spreading Ansible’s connection types callbacks — SSH is not the only transport possible — and even for adding new server side behaviours.
AnsibleWorks (AWX)
AnsibleWorks, which also sponsors the Ansible community, also produces the AWX. It is a web-based solution to make Ansible simpler, and to provide a trouble-free usage for the IT companies. It is also designed to be complete all kinds of automation tasks.
AWX permits you to regulate the access and even allows sharing of SSH credentials, without someone being able to transfer those credentials. Inventory can either be graphically managed or synced with a wide variety of cloud sources. It keeps log of all your jobs and integrate them with LDAP. It also has an amazing browsable REST API. If required, the command line tools are also available for easy integration with Jenkins.
Conclusion
Ansible’s simplicity and ability to decrease the complexity of other tools has made it a reliable applicant for your environment. Its foremost concern is on security and reliability. It uses OpenSSH for transportation, and the language is designed around auditability by even those who are not familiar with the program. Ansible is suitable enough for managing both small setups with a handful of instances as well as the enterprise environments.
Software development has undergone a massive transformation in the last two decades. From the first wave of breakthrough do-it-all PC applications such as Lotus 1-2-3 and Microsoft Office, to the launch of the first iPhone and its all-new “app” category, to the recent release of the iWatch and its projected evolution of apps, developers have never been more in demand to support these new technologies.
In May, my company Gemini Solutions will be celebrating our 10-year anniversary, and we’ve been fortunate to have worked first hand on huge advancements. Our close partnerships with some of the most innovative technology companies have given us firsthand insight into areas of significant change, growth and importance for software engineering.
1. Mobile Keeps on Rolling
The biggest area on the horizon for developers is the increasing prominence of mobile. Active in the mobile space since 2007, we have seen the demand for mobile-focused projects explode in recent years, and anticipate it is only going to get more popular. This space has seen incredible change in just a few short years. iOS app development continues to be the most requested, but we’re seeing a lot of growth in Android as well and expect it to continue to gain prominence as more Android devices enter the market. As Microsoft establishes itself as a platform, its apps will not be as in demand as iOS or Android, but I have a feeling that we’ll see growth for them as well.
2. Be Aware of Wearable Apps
Apps are no longer limited to mobile and are branching out to new devices, such as smart watches and bracelets, as they gain in popularity. There’s been a lot of buzz around Apple’s iWatch and the demand for the device is expected to be huge. We’re already receiving requests for the development of wearable apps so companies can keep up with the technology. Many of the inquiries are consumer-focused at the moment, but are beginning to move into the enterprise as well as these devices have the potential to become a one-stop-shop for both everyday and business uses. In addition, we believe that connected app development is also going to increase sharply in prominence. As these new devices link to mobile phones, tablets and computers the demand for interconnectivity is going to be huge.
3. Functional Programming Making a Comeback
We’ve noticed that the functional programming model is starting to see an increased push again. Scala is very popular for functional programming and is gaining traction with developers. We’ve also noticed people using Scala in conjunction with big data installations. JavaScript is immensely popular right now as well and we’re also seeing increasing use of Angular. This space is constantly changing and we expect to see even more infrastructures appear to offer more variety and choice for development.
4. It’s the Real Thing: The Internet of Things
The Internet of Things is the perfect amalgamation of mobile, embedded and cloud. The Internet of Things is bigger than the Internet of Humans. We’re seeing a lot of intelligent connected devices appearing on the market, and this is only going to accelerate as demand increases. A prime example is the popular internet-based security systems, with web-enabled locks, internet-controlled light and heating/cooling accessibility and the ability to view your home at any time via the device of your choice. Companies continue to make large investments in this space, prompted by the growing popularity of connected devices. We’ve been working with the Internet of Things for several years, but it is still a new frontier in many ways and we’re looking forward to being part of the space as it continues to develop.
5. Making a Big Deal About Big Data
In just a few short years, the hype of Big Data has gone from dream to reality. Everyone has their own interpretations of what Big Data actually means, but don’t let that fool you into thinking it’s a flashy trend; it is here to stay. The cloud is emerging as an increasingly popular way to develop and test new analytics apps and for processing big data outside of the enterprise. Data agility will also become even more central as organizations begin regularly using massive amounts of data, as opposed to just capturing and managing it. The umbrella of big data covers many disparate applications. Being able to analyze massive amounts of data to determine user activities, actions and preferences will be priceless to companies, and is why we will continue to see this space explode in popularity.
The software development space has never been constant or stagnant. Huge advancements and innovative new technologies are continuously appearing to change the game and open up new possibilities. We have been honored to be part of this movement for the past decade to help drive these crucial projects forward. If the past 10 years were any indication, the future of software engineering will be bright, unpredictable and unfathomable. I can’t wait to be there for the next chapter.
About the Author/ Theo Nissim
Theo Nissim, CEO, Gemini Solutions – Theo is a seasoned Silicon Valley technology executive with more than 20 years experience. He has led pre-IPO start-ups, built dozens of technical teams, developed technology strategies and driven innovative products and solutions to market. One of Theo’s many strengths and passions is managing large scale, cross-functional development efforts to high profile product releases. Theo has held executive and management positions with large public companies, Sun Microsystems and Wind River Systems, and served as the Engineering Vice President for VC funded start-ups, Digital Fountain and AdKnowledge.
Theo has a Masters Degree in Computer Engineering from the Technion, Israeli Institute of Technology in Haifa Israel. He lives in Palo Alto, California, with his wife and twin boys.
This is 4th part of the multi-part series covering Automation, provisioning and Configuration Management. In this article best practices for Puppet shall be covered.
Puppet, one of the most well-liked configuration management tools, can also turn out to be complicated at times. In this post I’m going to briefly go through a few practices that have emerged as good, recommendable and high-level best practices. I would like to share some of them with the world so that the beginners get an advanced start.
1). Use Modules when possible:
Puppet modules are something everyone should use. If you have an application you are managing, add a module for it, so that you can keep the manifests, plugins (if any), source files, and templates altogether.
2). Keep your Puppet content in Version Control:
There is NO reason, not to use a version control system while developing puppet manifest/modules. You can pick your favorite systems — popular choices being Git, Mercurial or Bazaar which prove to be particularly useful due to the ease that they provide in managing multiple branches of code.
Version control is well-supported by the Puppet ecosystem. It is possible to use a mature Software Development Lifecycle to manage the development and maintenance of your Puppet manifests, tightly integrated with a branch-based workflow that truly realizes the ideals of “infrastructure-as-code.”
Using version control helps in opening up of lot of additional possibilities with puppet, like better tracking of changes, testing your Puppet manifests in an isolated environment, promoting your configuration from environment to environment, etc. Version control even provides a free backup for your configuration code.
By making a use of a collaboration tool like Github or Bitbucket, you and your team can easily revise each of the changes separately before they are applied. This results in much better, more sustainable Puppet code. Placing all your Puppet files under version control is counted as one of the best Puppet practice and whenever you are ready to “deploy” any kind of changes to your Puppetmaster, you just have to sync the working copy on the server with the code in the version control repository.
3). Make use of Environments:
Environments are isolated groups of Puppet agent’s nodes. A Puppet master server can serve each environment with completely different main manifests and module paths. Puppet has this concept of Environment that helps in applying your configuration changes on less critical servers first and after the changes has been tested and ready, then promoting those changes to production. This frees you to use different versions of the same modules for different populations of nodes, which is useful for testing changes to your Puppet code before implementing them on production machines.
Staging and production are two Puppet environments that are used where Staging environment is used at an initial provisioning of a server to all pre-production boxes and production servers make use of the Production environment. Both environments are tied to a specific branch in Git repository i.e., “master” branch in Git is production and “staging” branch is staging.
4). Use dry-runs:
Even with the best precautions taken, sometimes your Puppet manifest doesn’t do exactly what you expected. Things can get messy at times whenever you actually get to run the Puppet agent to apply your configuration updates on your servers. For example, if it would update a config file and restart a production service this could result in unplanned downtime. Also, sometimes manual configuration changes are made on a server which Puppet would overwrite.
To reduce the risk of problems, you can use Puppet’s agent in “dry run” mode (also called noop mode, for no operation) using the following options:
puppet agent […] –verbose –noop –test
By making use of this practice you will be able to see the difference for all files that would modify as well as validate things according to your expectation. It will help Puppet agent to only show what it would do, not what it did.
5). Managing Puppet modules with librarian-puppet:
Handling module dependencies can sometimes become a source of worries, especially when several numbers of people are working on Puppet code and each one demand to test it on their own computer. Librarian-puppet is a bundler for your puppet infrastructure that helps in providing sanity to the process by automatically managing your module dependencies.
Librarian-puppet manages your modules/ directory based on your “Puppetfile”. The tool will install, update or remove modules automatically when you run it, always matching what’s specified in the Puppetfile. Your Puppetfile becomes the authoritative source for what modules you require and at what version, tag or branch.
Once using Librarian-puppet you should not modify the contents of your modules directory. The individual modules’ repos should be updated, tagged with a new release and the version bumped in your Puppetfile. It will help resolving and installing modules’ dependencies and become aware of compatibility issues.
Librarian-puppet simplify deployment of your Puppet infrastructure by automatically pulling in modules from the forge and git repositories with a single command thus saving you from installation and managing your modules manually. Deployment normally comes up with following two simple steps:
Sync your main sources with your code repository (ex: git pull)
Run librarian-puppet to synchronize your installed Puppet modules
Don’t use Git dependencies with any version specifier
6). Keep sensitive data safe:
Today Data security is the key concern for any organization. Some data always needs to be kept safe. For example, for maintaining the data security it may be required to put in your Puppet code in passwords, private keys, SSL certificates and so on.
Don’t put Puppet code in version control unless you’re absolutely aware of the risks you’re taking while doing so.
If you’re already a bit familiar with Hiera which is a Puppet tool, you know why it’s a good idea to separate your data from your Puppet manifests. In case you aren’t familiar, though, using Hiera leases you write and use reusable manifests and modules. After you store your organization-specific data in Hiera, Puppet classes can request the data they need from your Hiera data store.
Hiera allows you to store data about your servers and infrastructure in YAML or JSON files. From usage, you’ll see that most data in Hiera files is not confidential in nature… so should we refrain from using version control for Hiera files just because of a few elements that are unsafe? CERTAINLY NOT!!!!!!!!!!!!
The trick is to use Hiera’s ability to combine multiple data sources or backend
or
What you can do is split Hieradata files into 2 types: YAML files for your “main” Hieradata files and JSON files to store your “secured” data. Those JSON files are not to be put under version control and are stored securely on a single location i.e., “the Puppetmaster”. This way, very few people can actually see the contents of the sensitive files.
7). Producing abstractions for you high-level classes:
Wrapping up all the uses of modules into a covering or let’s say into a wrapper classes provides higher-up maintainability of the Puppet code in time. For example, Assume you want to setup a reverse proxy server using an existing Nginx module. Instead of directly assigning the ‘nginx’ class on your nodes and setting all of the required stuff up, create instead a new class called, say, ‘proxy_server’ with the attributes you want to consider for your proxy server as class parameters. Assigning the ‘proxy_server’ class on your node not only better states your intent, but it also creates a nice little abstraction over what you consider as a “proxy server”. Later on, if you decide to go away from Nginx (highly improbable) or use another Nginx module (more probable!), then you’ll probably just need to change the content of your “proxy_server” class, instead of a bunch of tangled node definitions.
In the End:
Puppet isn’t the only Configuration management (CM) tool available, but it is the most mature, with a large community of active module developers. Implementing these practices will help you in getting the most out of the Puppet.
***This post is based on themes and ideas from the great e-book, “Continuous Testing,” by our friends at Parasoft.
Enterprise software development models have presented many innovative solutions for IT to align development efforts with business goals.
Adopting new software development lifecycle methodologies is as much a business decision as an IT decision. From an IT perspective, this means the ability to produce profitable products at lower cost without compromising quality.
Maintaining quality through the code changes to add features and push new releases has been a struggle until the inception of the DevOps-driven Continuous Testing model, which transforms costly, time-consuming IT practices into profit centers.
The DevOps Patch to Agile Pitfall
Having already adopted lean Dev and Ops strategies, Agile enterprise IT seems to have unlocked unprecedented efficiency and productivity by delivering better business value at a rapid pace.
But in all the mayhem and chaos in jumping on the bandwagon of the Agile development, IT teams ended up stockpiling a mass of false assumptions.
With this approach, teams ultimately ignored the true Agile philosophy of adapting, collaborating and planning, and ended up following an accelerated and reinvented version of Waterfall in hopes to develop fast, deliver early and manage issues effectively.
A change was needed somewhere between design and development, and release and production phases where IT teams were failing to identify software defects and perform fixes fast enough.
The lack of early, adequate, parallel and continuous testing was transforming IT into a cost center by drawing unnecessary expenses and time investments in reworking software to meet desired quality standards.
The DevOps approach aims to address this challenge by facilitating continuous testing as an ongoing effort to identify and fix software defects early and deliver the right quality at the right time at the right cost.
Continuous testing presents the following value propositions to raise business bottom line and open doors to unprecedented revenue opportunities:
Informed Decision Making
Business expectations about the reliability and speed of application delivery vary throughout the SDLC.
Continuous Testing creates a centralized system identifying failures and defects that present business risk to the organization.
Continuous Testing as a consistent effort provides adequate visibility and useful, real-time data. This can be a huge advantage to businesses, especially when it comes to application performance monitoring and testing.
The assessment of stability and validity of software builds enables Ops and business decision-makers to trade off decisions between risk and time of release, cost investments, functionality, scope and quality.
Business Agility and Competitive Differentiation
Enterprises across all industries have development shops delivering software applications as core components of their service offerings.
These departments, often driven by DevOps, must focus on churning out new, stable and high-quality software and race to deliver a stream of features that complement primary service offerings.
For instance, mobile check deposit was a leading driver for bank selection a few years ago and financial institutions offering this online service (while doing it well) early gained valuable competitive differentiation.
In the DevOps world, Continuous Testing creates a safety net for DevOps teams to develop, test and release new features to the market faster without compromising quality. This safety net works as a trusted testing environment, suite and tool to assess the impact of code changes accurately and quickly.
With these capabilities, organizations gain the agility to bring new products to market and compete on innovation and not on the scale of business operations and investments.
All in all, great DevOps levels the playing field between the eight-person startup and the massive enterprise competing in the same space. Who releases faster with a better product is more dependant on the process, not the funding.
Stronger Business Performance
IT performance is business performance. It’s measured in terms of the quality, productivity and functionality of IT solutions delivered for internal business operations or as marketable products.
The primary objective of Continuous Testing is to ensure high quality software products are delivered on time, cost and scope. To achieve these goals, IT teams need capabilities such as automation-driven, self-testing builds in a clone of production environments.
QA is expected to leverage frameworks and automation tools that allow testing early during the lifecycle. That shrinks time spent on test setup and maintenance, using service virtualization to replicate unavailable testing environments and establishing a comprehensive quality validation process with continuous integration systems.
These practices work as core elements of Continuous Testing to test faster, sooner, more often and continuously, thereby boosting IT and business performance.
These business values not only generate unprecedented new revenue streams but also unlock cash trapped within the business IT.
The resulting increase in revenue encourages organizations to change their game entirely and pursue new DevOps-driven business models in improving service delivery, scaling operations immediately and competing on fronts of business innovation.
Industry studies and market indicators show the exploding growth of the DevOps movement, and it’s for one simple reason – in today’s application driven economy, DevOps teams have proven that they can build, test and ship applications faster than the traditional IT approach.
Businesses compete on the efficiency of delivering applications to meet the demands of the critical mass. Enterprises need the latest business applications to meet new service demands of their customers, accessed in new ways such as over mobile devices. In an application-driven economy, apps are developed and delivered via the cloud more rapidly than ever before; fast time to market is key for success and staying a step ahead of the competition.
As a result of this incredibly dynamic environment, IT teams have adopted new processes such as “continuous integration, continuous development” (CI/CD) – a radical departure from the waterfall model of application development that’s been around for decades. These people and groups within organizations that are leading the charge on CICD or agile development – to meet economic demands for the exploding cloud and mobile market place – are called “DevOps”.
However there are three big barriers that are still slowing down the time to market for apps. Unfortunately, there’s not much the DevOps folks can do since the problem lies in how underlying enterprise IT infrastructure, and specifically the networking products such as application delivery controllers (ADCs), have not kept pace with this evolution.
The reasons application delivery to market is still too slow, as well as recommended solutions, include:
Network admin “Human Latency”: ADCs are usually purchased by the network admins that sit within the CIO–led IT teams. As a result, the DevOps and application developers don’t have access to ADC devices. Since app developers need ADCs to test the efficacy of the apps they are building, they have to connect with the networking teams and request access to ADCs…and wait for permissions. This typically takes weeks because of the complexity involved with setting up a custom environment per app developer per app!
In a world where it takes 20 seconds to fire up a server, the human latency (measured in weeks) associated with provisioning an ADC is simply unacceptable.
The solution: A fully programmable , self-service ADC that the app developer/DevOps folks can themselves setup within seconds using RESTful API and scripting tools. DevOps needs an ADC that has zero touch provisioning, is able to auto-discover the compute/app environment, and can auto-create and auto-scale.
Distributed Microservices-based app architectures: Microservices have fundamentally changed how apps are built, maintained and scaled. Instead of a monolithic “black box” app that sits in one location with a “reusable or even disposable lego-block” architecture, Microservices can be written in different programing languages, loaded on various hardware and hypervisor platforms, and, most importantly, deployed across various on-premise and cloud locations.With this heterogeneity comes complexity in managing all these different environments which leads to cost and delays associated with rolling out a new application.
The solution: An application delivery architecture that can span, serve and scale all locations, while remaining one device to manage from a management perspective.
Geographically dispersed Dev, Test and Production teams: Many companies have the development and testing of apps done in a public cloud, but because of data sensitivity issues (or compliance) they have to run production copy of the app on on-prem data centers or private clouds.Imagine for a minute what this means – completely different environments across various cloud/on-prem locations!When doing development or testing, a certain ADC can be used on-prem – but it’s a different ADC for the real world. There can be unexpected surprises in terms of how the app actually behaves, performs and scales in a real deployment.
Solution: DevOps teams need the same consistent environment across public, private and on-prem data centers. More importantly, if the setup and operations of ADCs across environments is identical, it saves a lot of complexity and costs.
The goal of the DevOps group is to make the organization successful by increasing IT performance and delivery. It aims to make life of an app developer and tester simpler, allowing enterprises to develop and roll out their own apps faster than the competition. From a recent study by Puppet Labs, analysts noted: “We wanted to test the hypothesis that IT performance actually does make a difference to organizational performance. We found that IT performance strongly correlates with well-known DevOps practices such as use of version control and continuous delivery. The longer an organization has implemented — and continues to improve upon — DevOps practices, the better it performs. Companies with high IT performance are twice as likely to exceed their profitability, market share and productivity goals, giving them a strong competitive edge. “
Now more than ever, companies need to be committed to the DevOps model to keep up with the constantly changing business landscape. New approaches to DevOps addressing the challenges of today’s dynamic environment are available for companies to leverage for the benefit of their customers. The timing could not be better – it is now. However, an evolution of the underlying IT infrastructure such as the application delivery controllers (ADC) is not just desirable but mandatory.
About the Author/Ranga Rajagopalan
Ranga Rajagopalan, CTO and Co-Founder of Avi Networks. Over the last 15 years prior to co-founding Avi Networks, Ranga has been an architect and developer of several high-performance distributed operating systems as well as networking and storage data center products. Before his current role as CTO, he was the Senior Director at Cisco’s Data Center business unit, responsible for platform software on the Nexus 7000 product line. Joining Cisco through the acquisition of Andiamo where he was one of the lead architects for the SAN-OS operating system, Ranga began his career at SGI as an IRIX kernel engineer for the Origin series of ccNUMA servers. Beginning his journey with a Master of Science degree in electrical engineering from Stanford University and a Bachelor of Engineering in EEE from BITS, Pilani, India, he now has several patents in networking and storage.
Ansible Tower is used in a variety of different ways, from traditional configuration management, to custom application deployment, to the orchestration of zero-downtime rolling updates. Companies like Gawker Media use Ansible to deploy their sites more than 10 times an hour. NASA uses Ansible to update security vulnerabilities and to patch manage nasa.gov weekly. Enterprises that make money delivering applications via the web find that Ansible Tower excels at removing IT bottlenecks, automating repetitive tasks, and accelerating the delivery of applications to market.
For IT operations, rolling updates with zero downtime is a very common orchestration pattern that has been discussed at length, but let’s take a look at how Ansible Tower fits earlier into the software development lifecycle and removes bottlenecks in operations, as well as in in development and test.
Ansible Tower offers a number of benefits in the SDLC, specifically to:
Drive consistency between environments
Enable self-service
Improve automated testing
Development
A typical day in the life of an application developer may be to: check out code, make changes, test locally, check in changes.
During the course of this work, the development environment may become infected with small configuration tweaks and hand-crafted software stacks that differ dramatically from the environment that production code is ultimately deployed to.
In fact, a common problem in many organizations is that the development environment may not exactly (or even closely) match what’s in QA, Stage, and Release. Generally, the further away from production you get, the less and less the environments look the same. (Not just the obvious examples like software library versions, but more subtle items like configuration settings, authentication details, etc.).
Inconsistency between code and the software stack that supports the application is a common cause of software errors and resulting production downtime. With Ansible, a playbook captures the desired state of the stack and even the entire environment. Ansible Tower provides a push-button interface that templates how a playbook should be run — deploying consistently and with repeatability.
With Ansible Tower, a playbook is run from a job template, which specifies the parameters and environment details of how to run the playbook, with all of the parameters and options you would normally pass via the Ansible command line. There is no concern that the user will mistype an option or parameter to Ansible, potentially deploying to the wrong environment or with the wrong playbook arguments since the template is triggered via the push of a button (or API.)
Not only do these templates drive consistency between deployments — each time the button is pressed the same result is expected — but they also encourage a tremendous amount of playbook reuse: Multiple job templates can be created that launch the same identical playbook with different parameters. This enables the same playbook to be used between environments or stages of release. The job template can use the same playbook, but target different inventories (corresponding to different stages of release or different environments), pass different options, even use different credentials.
This drives consistency between releases, even across different stages, by ensuring that the same steps to automate provisioning and deployment are followed between each stage.
Screenshot of how to use different job templates with the same playbook, passing different parameters from the user to deploy into different environments
When combined with the the role-based access control capabilities of Ansible Tower, playbooks can be deployed at the push of a button, but in a controlled and easily-audited way. This allows an organization to spread the power of Ansible to any of its users. Even users unfamiliar with Ansible can run playbooks that others have written.
These features are commonly used to enable self-service provisioning of development environments by the developers themselves.
Typically, developers manually construct a development environment that starts out only loosely coupled to the production software stack and deviates further and further over time. Alternatively, developers are forced to request a new development environment from operations teams, usually incurring delays that proliferate throughout the software development lifecycle and lead to late deployments, missed deadlines, and lost business.
Tower enables developers to check out and provision their own development environment, built from scratch and 100% consistent with the software stack used in test, stage, and production — because it is built with the same playbook. Developers log into Ansible Tower and, under RBAC, see only the job templates that they have permission to access and deploy.
Developers do not require any knowledge of Ansible or the playbook. They can provide new parameters and options, specifying perhaps the release tag of the application to be deployed or fine tuning the deployment to fit within the constraints of the environment. The playbook handles provisioning the new servers (e.g. by calling out to VMware or Amazon Web Services), deploying and configuring the software stack, and the actual application under development. The developer presses a few buttons in Ansible Tower, goes and gets a cup of coffee, and then returns to a newly 100% provisioned environment. Tear down and re-provisioning is a snap, so a new environment for pristine development can be deployed at any time.
QA
A typical day for QA might look like this: Program a CI tool to automatically build the codebase periodically, deploy to a test environment, run tests, report results.
At most shops, some of this work is generally automated, usually building the latest code and the deploying the latest code artifacts into test. Deployment of the application stack may not be automated (or easily refreshed between test cycles), leading to the same consistency problem as in development,or worse, because test environments and artifacts are potentially reused between test cycles. Here again, the reuse of playbooks between environments through the Ansible Tower job template will promote consistency between stages of release.
Additionally, the same Ansible Tower self-service capability that can be provided to developers can also be provided to testers. QA may write their own playbooks for automated testing and Ansible Tower can be used to delegate responsibility to QA staff who are not Ansible experts or aren’t comfortable running Ansible on the command line.
In addition to self-service, it is very common to use Ansible Tower in conjunction with a Continuous Integration system in QA to automate not only application deployment in test, but provisioning of the application stack to refresh the test environment between tests.This way, Ansible Tower provides a complete RESTful API that powers the Ansible Tower user interface and makes it possible to programmatically invoke Ansible Tower to do any function that can be performed via point and click in the UI. In this way, a CI tool like Jenkins can be connected to Tower to launch job templates for automated testing. Jenkins is configured to call the Ansible Tower API to launch a specific job template that invokes an Ansible playbook to provision a new QA environment, deploy and configure the appropriate software stack, the correct version of the application, and the test suite. Automated testing can be performed and the environment decommissioned, all within one or more playbook runs.
Just as in development, this ensures that the test environment is consistent with all release stages — that what is being tested is the same as what was developed and what is being deployed into production. Test environments can quickly be provisioned and deployed 100% from scratch, improving your ability to test and to speed up the application to production delivery.
When used in conjunction with with a CI tool like Jenkins, the combination is more powerful than with a CI tool alone: Jenkins can kick off Ansible playbooks to provision environments and deploy the latest code as part of any Jenkins CI job, but under the framework of role-based access control, inventory management, and aggregated job output that Ansible Tower provides.
As you adopt Ansible Tower into Operations, consider also the benefits of Ansible and Ansible Tower throughout your software development lifecycle. Apply automation to eliminate bottlenecks through every stage of release and accelerate the delivery of your applications to market.
Let me know how you are using Ansible Tower in your efforts – we want your input!
Dave Johnson, Senior Technical Director, Ansible. Dave started his career at Red Hat prior to its IPO, ultimately building and leading the sales engineering organization that penetrated the US Oil & Gas, Electronic Design Automation, and Managed Service Provider markets.Prior to joining AnsibleWorks, Dave held executive positions at rPath and Bronto Software, leading engineering and services organizations that spearheaded the transformation of innovative custom solutions into repeatable Products.Dave holds a B.S. in Electrical Engineering and a B.S. in Computer Engineering from North Carolina State University. Contact info: @thisdavejohnson, Linkedin
