devopsy.kinsta.cloud

Category: Blogs

  • Is DevOps a Competitive Advantage? A Debate

    Is DevOps a Competitive Advantage? A Debate

    The idea of DevOps being a competitive advantage is not a new one. Service providers, software sellers, and internal IT frequently use this argument to justify all kinds of investments. But is there any real merit to this argument? Is DevOps truly a source of sustainable competitive advantage? Or is it simply just hype and a new way to sell a product / service?

    Here are some of the more popular points of view from both sides of the aisle.

    “Yes Absolutely” “No, Go Take A Hike”
    Speed is sexyIn the mobile, social, and web world customers expect speed and responsiveness. Bringing an idea to the market faster than your competitors is definitely an advantage and DevOps allows us to do just that. DevOps is not the only fish in the seaAgreed that speed is sexy. But at this given moment there are multiple technologies / philosophies out there that claim to do the same – i.e. cloud, big data, analytics etc. What makes DevOps so different?
    DevOps is hard to replicateWhile purchasing tools is easy, the real benefit lies in getting the culture and process right. Any organization that can get that right will be able to form a sustainable competitive advantage. Same has been said about other strategiesRemember when outsourcing started. It too was touted as a sustainable competitive advantage. Now it is the de facto strategy for IT erasing any advantages that the early adopters had. DevOps, if it does take off, too will follow the same path.
    New IT operating modelDevOps represents a new way for enterprise IT to operate. It breaks down the silo structures and unlocks the value trapped within the existing organization. Enterprises are not start-upsJust because it worked in a start-up environment does not mean that it can work in a large enterprise.
    Listening to customersSpeed is only one equation of DevOps advantage, the other is faster feedback loops so that you can determine that you are going in the right direction. Combine the two and you have a powerful competitive advantage. Not an IT responsibility / competencyIsn’t that what most organizations already do? I have my entire business / product / marketing org. focused on just that. The last thing I need now is IT to jump in and muck it all up.
    The new Software Delivery LifeCycle (SDLC)DevOps represents a new way for enterprise IT to operate. It breaks down the silo structures and unlocks the value trapped within the existing organization. Just good marketingThis is just repackaging of an old wine into a new bottle…DevOps is just a new thing. Like all other fads this too will pass.

     

    My Take

    Allow me to be the quintessential consultant and speak from both sides of my mouth. DevOps is and is not a competitive advantage. Now before you close the browser and move on, let me explain.

    DevOps in the short term is most definitely an advantage. Moving an organization from Traditional to a DevOps approach is not an easy task. Any corporation that can successfully achieve this transformation will be the first to reap its benefits – from faster speed to market to being more responsive to their customers. And the benefits are real! Ask Netflix and Etsy, who have been able to out innovate their competitors and gain a sizable lead in the market.

    However, in the long term, as more and more firms invest in DevOps the advantage will continue to shrink. DevOps, if you strip all the marketing jargon and go down to the most basic definition, is about reorganizing the internal plumbing of IT (i.e. how IT performs the various tasks within the software delivery lifecycle). And while in the short term plumbing can allow you to do some neat stuff, at the end it’s only internal plumbing and rarely a source of lasting competitive advantage.

    To see this is action, look at the automotive, financial, and then our very own Information Technology industries. In all three examples, the company that was able to transform was able to establish an early sizeable lead, reap the rewards, and the rest of the industry forced to catch up eventually.

    In automotive industry, early investment in lean and TQM earned Toyota customer loyalty and a significant lead over its traditional competitors. And while the lead lasted for a decade (short time in an industry where product lifecycles are 4 – 5 years), competitors quickly started to invest and catch up. You can now argue that U.S. manufacturers are at par with Toyota in both quality and speed. Where the competitors have still not caught up is in perception.

    In the 1970s it was not unusual for a home buyer to wait for up to 90 days to get a credit decision and a loan, as per “industry standards” in those days. Citibank rearranged its internal processes to give buyers a decision in 30 days. It took the industry by storm. Competitors eventually caught up and now 30 days is the norm.

    And as for our very own, Information Technology industry…outsourcing was considered to be a competitive advantage for many of the first movers. Like other strategies, it too required a structural change to make it happen. Many of the initial pioneers were able to cut IT costs by over 30% and establish a cost advantage over their competitors. But within a decade competitors copied, banked the savings, and eroded the cost advantages.

    In my opinion, DevOps too will follow a similar path. A few leaders will emerge (already happening), they will set the pace of change for the industry, and the rest will have to follow….whether they like it or not.

     

    About the Author

    MustMustafa Kapadiaafa Kapadia is the Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery.  He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.

    Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and adviser to start ups.

    Connect with Mustafa LinkedIn| Twitter

  • 9½ Simple Steps On How To Start With DevOps Today

    9½ Simple Steps On How To Start With DevOps Today

    Isn’t it funny that a lot of people, me included, don’t really know the difference between DevOps and Continuous Delivery? Wikipedia tells that both are pretty much overlapping. In order to continuously deliver one must be familiar with DevOps. Anyway, I will tell you what you can do now to start with DevOps and Continuous Delivery. Here are 9½ simple approaches that tell how you can start immediately.

    (more…)

  • Live Blogging DevOps Connect @RSAC

    Live Blogging DevOps Connect @RSAC

    We will be live blogging the DevOps Connect: SecDevOps event from RSA Conference on Monday, April 20th. Stay tuned for updates

  • DevOpsQA NJ Meetup – Virtual Networking with Project Calico

    DevOpsQA NJ Meetup – Virtual Networking with Project Calico

    devopsqa1DevOpsQA NJ held our April Meetup on Virtual Networking with Christopher Lijenstolpe as a speaker.  The meetup was held at the new venue, a state-of-the-art office space overlooking NYC,  kindly provided by Ishi Systems.

    Christopher, who is a Director of Solutions Architecture at Metaswitch Networks , is also the original architect of Project Calico.  Before joining Metaswitch,  Chris ran networks across the globe including Antarctica.

    We got a detailed overview of Project Calico,  which is Apache licensed, pure layer 3 networking solution for container, VM, and hybrid environments.   It’s motto is Scalable, Simple, Open and from the looks of it,  it meets all 3 of those criteria.

    Chris started with introducing us to the Standard Virtual Network Model,  and demonstrated the unnecessary complexities of today’s networking systems.  While all these systems are trying to address a multitude of assumed requirements,  the only Real requirement is to establish Communication.  This complexity results in various issues such as fragile connection, poor performance,  inefficient resource utilization and difficulties in troubleshooting.   These issues are significantly magnified when it comes to Containers.

    So what is Project Calico?   As Christopher simply explained,  it proposes to build data center like the internet,  utilizing 3 key components –  BGP,  IP and Policy.  In Christopher’s words,  “Project Calico is so simple that it was hard to believe no one thought of it before”.  And that is a real  indicator of a truly innovative solution.   If you would like to try out Project Calico on OpenStack or Docker,  you can read more information at http://projectcalico.org  or contact Christopher directly at christopher@projectcalico.orgProject-Calico-logo-456x456-no-text

  • Cyber-Ranges, Cloud Automation and DevOps

    Cyber-Ranges, Cloud Automation and DevOps

    Cyber-security testing typifies some of the challenges of converting from traditional to DevOps ways of doing IT.  While cyber security labs and cyber-ranges are often mission-critical investments for organizations that find themselves to be high-value targets for cyber-attacks, too many times cyber-security testing processes are siloed and highly manual.  It’s time for cyber-ranges to move towards DevOps.

    Cyber-ranges are essentially lab infrastructures that are used for a variety of security-related activities including point product testing, network topology-level testing, and training such as red team/blue team exercises.  While cyber-ranges have typically been used by government and military organizations, increasing numbers of business organizations such as financial institutions and utilities are building these infrastructures to ensure that they are as equipped as possible to anticipate, respond and thwart attacks.  Particularly when the running assumption is that increasingly mobile and porous IT boundaries will inevitably be compromised, the ability to respond rapidly effectively is critical.  This means that beyond product testing, developing response skills and systems is a key function.

    All this is of course good and very important stuff.  So what’s the problem?  Well, like many IT-practices, cyber-ranges most often live in their own silo.  It is very uncommon today for a cyber-range to be part of a broader continuous integration or continuous delivery testing cycle addressing applications and infrastructure.  In fact, far from being part of a continuous process, it’s exceedingly common for cyber-ranges to be operated in a highly manual fashion, which means that changes happen slowly and painfully, productivity is low relative to the significant investment they represent.

    How Cyber-Ranges Work Today

    The cyber-range market today is addressed by two main categories of solutions: bespoke deployments performed mostly by small to mid-size systems integrators, and expensive “cyber-range in a box’ solutions offered by large systems integrators that have packaged a set number of functions under typically, a monolithic management application that is driven by an operator GUI.  The advantage of the latter obviously is that it makes it much easier for users to operate, but these “in a box” systems are built for a discrete, siloed set of operations and they typically rely on vendor roadmap-driven updates to extend functionality or update support for new infrastructure or tools.  Ironically, that makes them less agile.  As for the bespoke deployments, they are very manual in nature—just setting up a scenario for a test can take a week or more, which is right in line with the timeframes associated with non-cloudified IT infrastructure.  One of the ways that Gartner describes DevOps is as a “pairing of agile methodology and systems thinking”.  In both aspects cyber-ranges today are far from DevOps.

    Cloud Automation is Key to DevOps-Friendly Cyber-Ranges

    The path for cyber-ranges to follow to get into the DevOps slipstream is primarily an issue of cloud automation.  Cyber-ranges are basically private infrastructure, because you have to utilize the actual networking and data center gear that you operate to truly understand how exploits are going to affect them, what symptoms will look like.  Also, cyber-security issues really need to be worked out in realistic network topologies, which means that we’re talking about staging/delivery type testing environments.  What’s needed is to turn these complex infrastructures and be able to rapidly stand up, tear down and revision these infrastructure environments in a private cloud fashion.  A cyber-range that is turned into a private cloud can support both UI and API-driven programmatic self-service.  Not only can cloud automation deliver tremendous short-term ROI benefits like a huge increase in productivity and resource utilization, but it also opens the way to tie cyber-ranges into a broader DevOps practice.

    In DevOps like life in general, no person or organization including the security team, is an island.  By moving towards a private cloud automation model, cyber-ranges can evolve from being a (very important) silo, and align with DevOps initiatives.

    About the Author/ Alex Henthorn-Iwane

    AlexAlex Henthorn-Iwane joined QualiSystems in February 2013 and is responsible for worldwide marketing and public relations. Prior to joining QualiSystems, Alex was vice president of marketing at Packet Design, Inc., a provider of network management software, and has 20+ years of experience in senior management, marketing, and technical roles at networking and security startups.

    Through his roles at QualiSystems, Packet Design, CoSine Communications, Corona Networks and Lucent Technologies he has acquired expertise in cloud computing and the opportunities presented through virtualization. He has written for Embedded Computing, Virtual Strategy Magazine, Datamation, SDN Central, Datacenter Knowledge and InformationWeek.

    Connect with him on LinkedIn, Twitter, or SlideShare.

  • The Hypocrisy of Vendor Neutrality

    The Hypocrisy of Vendor Neutrality

    Disclaimer: I’m going to name the product and company I work for in this article.  I assure you this does not mean this post is a product pitch.  Really, I promise.

    In my capacity as the open source community manager/dev relations/community evangelist/[Enter Alternate Title Here] at Cloudify, I’m a huge advocate of knowledge sharing. My personal credo is that the single most important element in a product’s success is spreading the wealth of knowledge — empowering your users to be autonomous, and even hopefully achieve a level of understanding that surpasses the original development team. Intelligence of the masses. Better code. Better product.

    To this end, I’ve been trying to cultivate a culture among our R&D to document document document everything you do.  I’m not talking about a product’s traditional documentation. I’m talking about those less formal processes of trial and error and learning that are never formally written down anywhere – and are lost when the person moves on to new endeavors, or even forgets after a time.

    I’m also a big fan of internal wikis…but that’s an even tougher culture to cultivate.  On top of toiling endlessly to write a great product, and then adding the necessary product tools to make sure people can actually use it – from docs to tutorials – the last thing devs want is the added overhead of actually having to document the technical aspects of the process.  So I relent.  But I have a dream, nonetheless.

    Backtracking to the actual topic at hand.  So in terms of interesting stuff my team is always doing – and working with excellent, awesome, interesting and cutting-edge open source tools – we write a lot of blog posts.  Really good ones (if I may say so myself) – technical, hands-on, useful…actionable posts.  Kind of like meta-documentation.  On top of these posts, and the existing tools we leverage in our daily work – we’ve actually discovered a lot of gaps with known tools, and have written additional open source tools that help us get the job we need done – not even as our primary work at hand, just as an added bonus.  And I’ve found a scathing irony/hypocrisy when it comes to propagating this knowledge to the masses.

    True story.  One of our devs did an excellent job of porting Vagrant .box files to AWS.  He wrote a really great post about it.  There was one caveat though, in the first line he had mentioned why he had needed to do so in the context of his work. He made the major faux pas of mentioning the product he did this for.

    I submitted the article to a prominent tech publication – and the response I received was:

    “Sorry your product is mentioned in the first paragraph of the post…we’ll need to pass”.  

    That was the only mention of the product in the entire post (btw, in this new post, we were actually asked to add a bit more info on the technologies mentioned in the article, hence the augmented intro. The initial post started with the pain point).  The entire post focused on Vagrant and AWS  – these products they had no issue with.  But the mention of our product in the first paragraph.  Tsk tsk tsk.

    Now, I truly and deeply understand that there are plenty of blog spammers out there.  Doing all kinds of SEO shenanigans to build traffic, and writing fluffernutter posts.

    But seriously just reading the article, and personally I felt this was one of the best written ones I’ve had, you can tell this one does not even remotely fall under the same category.

    So then I started to have a discussion with a team member who really likes to write posts.  And I love him for that.  And we asked the crazy question of… when do you reach that critical mass that you can freely mention your product and its values in the context of other technologies and technological needs without being perceived as pitchy?

    Why are certain technologies from the Vagrants to the Dockers (open source) and the AWS to VMwares and even Apples (not even remotely open source) given a stage to discuss the benefits of their products without being perceived as pitchy – while others are completely passed over or even scorned for their mention?

    Is it a critical mass thing? A tipping point? Is it what delivers traffic?  How can you know a product won’t deliver traffic if it’s not allowed to be mentioned? How can a product garner adoption if it isn’t known about?

    And let’s be honest, nearly all open source tooling these days has a monetization angle – people can’t work for free, it just isn’t a sustainable model.  So every single tool out there has what to gain.

    So who are those powers that be that decide which product is worthy of being mentioned, and those that are only possibly allowed to be mentioned (best case scenario) in the author’s bio?

    The even bigger irony is that these sites that are offered these technical posts, and are monetizing themselves off of these contributions, and building their own reputation and traffic and traction and SEO…

    I’m not intending to sound bitter. I know these sites receive A LOT of content, and have to be very strict with moderation.  I get it.  I also know that while pastures may seem green to us on this side of the keyboard – tech sites from the prominent GigaOms to the more niche Dr. Dobbs are shutting down left and right.

    And this is where I have to give a shout out to the DZones, devopsy.kinsta.cloud and Developer.coms of the world – who do understand the technical worthiness of posts that albeit mention a now esoteric product, but provide information of technical value to their readers, and publish them.

    Who knows – maybe the sites that have the foresight to give respect to new tooling will have gotten in on the ground floor of the next Docker.  (Because you just can’t have a technical post without mentioning Docker.)

  • DevOps and the Case for ROI to Executives

    DevOps is hot and likely top of mind for your executives.

    Every IT analyst firm now has a point of view (POV) on DevOps. International Data Corp. (IDC) for example believes that DevOps will be adopted (in either practice or discipline) by 80% of Global 1000 organizations by 2019 (read: IDC MaturityScape Benchmark Assesses DevOps in the United States).

    DevOps events, conferences, web sites, meetups, and communities are proliferating like wildfire. For example, the devopsdays conferences started with a single event in 2009. Fast forward to 2014, through DevOps’ meteoric rise…18 devopsdays events were held at locations scattered far and wide across the globe.

    IBM DevOps PracticsThe top IT vendors all have DevOps product lines and consulting services, and new technology startups and VC funding continually enter the space. Why? Organizations need to deliver more applications and systems faster with higher quality, at reduced risk and expense. Downtime has become untenable at any cost, and every second of time to recovery equates to lost revenue. DevOps addresses these challenges through improved collaboration, workflow, and automation solutions, based on proven Agile and LEAN principles and techniques, that improve speed to market and reliability. A DevOps approach delivers technical and business results to LOB leaders, the C-suite and to IT app delivery and operations.

    Organizations need to deliver more applications and systems faster with higher quality, at reduced risk and expense. Downtime has become untenable at any cost, and every second of time to recovery equates to lost revenue.

    If you are responsible for justifying investment in new mobile or cloud app platforms, or modernizing enterprise apps, or implementing a DevOps solution for continuous delivery, then our upcoming webinar will be of interest to you. When you ask stakeholders to change what they’ve done successfully for years, and adopt a DevOps approach, you must monetize the benefits and ROI for them and make the organization change real. Like any change in approach, investment and ROI are required before it will be adopted and scaled widely. And like any executives who sponsor or fund an investment, your executives will want to see a significant, monetized payback, and the quicker the better. As you know, senior executives in the C-suite love numbers, and those with dollar signs are even more endearing to them.

    Like any change in approach, investment and ROI are required before it will be adopted and scaled widely. And like any executives who sponsor or fund an investment, your executives will want to see a significant, monetized payback, and the quicker the better.

    Join Valerie Scott, Manager of the Shared Services Division at HM Health Solutions, and Peter Spung from IBM, as they discuss monetizing key DevOps benefits and associated costs. They will share a case study where cost benefit analysis frameworks were leveraged to justify DevOps ROI to senior executives.

    Valerie Scott and Peter Spung
    Speakers: Valerie Scott, HM Health Solutions, and Peter Spung, IBM

    HM Health Solutions invested in and adopted proven DevOps practices, such as: test-drive development, automated testing, streamlined code review, continuous integration, and continuous delivery via automated deployment.

    These practices have been rolled out across dozens of applications and environments thus far, and will be rolled out across hundreds in the coming months. The results have been stellar thus far:

    • a 67% reduction in resource demands on the release team & process,
    • a 75% reduction in relative hours to repair defects per environment,
    • and an 82% reduction in app deployment time

    This is just the tip of the iceberg as Val will describe — she’s just getting started on HM Health Solutions’ DevOps journey! And they are not alone. These results are typical and reflective of many other client cases studies and success stories, as Peter will describe.

    Please join us April 23 from 1 to 2pm EDT for what will be a very engaging and insightful discussion!

    You can register for the webinar here!

  • DevOps Security Talks At RSA USA 2015 Conference

    DevOps Security Talks At RSA USA 2015 Conference

    DevOps and security. Its a muddled mix of waters made even more confusing by the wet ink still on the concept of DevOps. There is no denying the popularity of DevOps and there is a lot of talk on how the DevOps movement functions alongside security teams.

    The annual USA RSA conference is just around the corner and its worth noting a handful of DevOps focused talks deserving of your attention.

    I am anticipating a lot of common themes around integrating DevOps and Security regarding tools, processes and culture. Given the history of these speakers, you can probably anticipate many of them to be on the bandwagon of security and DevOps folks better learn to work together and learn from each other or be prepared to find a new job.

    If I missed a talk that specifically covers the nexus of DevOps and Security at RSA USA this year, please leave a comment and I’ll be sure to get it included.

     

  • Get started with Docker with video training course from O’Reilly

    Get started with Docker with video training course from O’Reilly

    Container platforms seem to be the fuel driving the next wave of app development. Docker didn’t invent the concept, but Docker’s meteoric rise made container technology mainstream. Don’t worry if you’re still not quite sure what Docker is or how to use it—O’Reilly Media has you covered with its Introduction to Docker video training course.

    Catch the Docker wave

    If you aren’t already on the Docker bandwagon you’re a little behind the curve at this point. Docker breaks down barriers and enables developers to deploy apps more effectively and efficiently with less effort than traditional application development and deployment technologies. Docker lets you build an app in any language, and run it on any platform that supports Docker containers.

    At this point there aren’t many platforms that don’t support Docker. It has quickly become the de facto standard for container technologies. Microsoft has its own Windows Server Containers and recently introduced more secure Hyper-V Containers, but it also partnered with Docker to bring Docker containers to Azure, and it is working with Docker to integrate native support for Docker in the next release of Windows Server.

    In a nutshell, Docker is here to stay. If you’re developing and deploying apps its imperative that you know what Docker is and how to use it or you may get left in the dust.

    Learning Docker

    The Docker video training is presented by Andrew Tork Baker. Baker is an independent consultant based in Washington, DC and is a respected resource when it comes to Docker containers. He also goes by the handle “atbaker” and wrote spin-docker—a lightweight open-source Platform-as-a-Service powered by Docker and Flask.

    The entire training session is one hour and 46 minutes and costs $60 to download or stream from O’Reilly. You can watch the first three segments—about 10 minutes worth of content—for free to get a feel for the scope and quality before deciding whether or not to purchase the training.

    The video quality is adequate. Baker speaks a tad fast in parts—probably an effort to prevent the training from running too long or becoming boring. Overall, though, he speaks clearly and presents the materials in a way most people should be able to comprehend. That said, it’s an introductory course so don’t go into this planning on being a Docker guru in a couple hours.

    Baker covers a range of topics in the course. He starts from an overview of what Docker is (and isn’t) and how to set up your Docker development environment (both of those segments are part of the free preview), and then moves on to basic Docker concepts, working with containers, and finally to more advanced areas like Dockerfiles and how to deploy a Docker app to the cloud. The training concludes with recommendations for additional resources to continue diving deeper and learning more about Docker.

    There are only a handful of reviews for the Introduction to Docker video training course so far, but they’re all positive. So far it has an average rating of 4.5 out of 5 stars, and all of the reviewers would recommend the training to a friend. The reviews do stress that it’s an introductory course, though—just enough to give you a basic understanding.

    If you’re new to Docker or container technologies and want to get a grasp on the basics this is probably a good investment of $60 and two hours of your life.

  • Automation, Provisioning and Configuration Management with PUPPET

    Automation, Provisioning and Configuration Management with PUPPET

    This is 3rd part of the multi-part series covering Automation, provisioning and Configuration Management. In this follow up article best practices for Puppet shall be covered.

    Why Puppet?

    While every system administrator comes up with more progressive systems to be managed, the automation of every mundane task is increasingly significant.

    Instead of achieving in-house developed scripts, it is necessary to share a system that can be used by everyone, irrespective of one’s employer. But undoubtedly, this is not possible manually.

    So, Puppet has been developed to benefit the sysadmin community in building up and sharing of all mature tools, which prevent the replication of a problem which is being resolved by many.

    Following are the key methods followed by Puppet:

    1). It supports a powerful framework, and is responsible for simplifying most of the technical tasks required to be done by the sysadmin.

    2). The sysadmin’s work is written in form of code, easily sharable as the other pieces of code, in the puppet’s custom language.

    The Puppet usage accelerates your work as a sysadmin, as it supervises and handles all the details. You can download the code from other sysadmins to help you get your work done even faster. Most of the Puppet implementations make use of one or more modules already developed by others. One can find hundreds of modules developed and shared by the community.

    What is Puppet?

    Puppet is an open-source IT automation tool developed by Puppet Labs. Its written in Ruby; composed of a declarative language for expressing system configuration; a client and a server for distributing it; and a library for realizing the configuration. Puppet helps in automation, deployment and scaling of applications in the cloud or on site.

    The basic design objective of Puppet is to come up with a powerful and expressive language backed by an influential library that makes you write your own server automation applications in just a few lines of code. Its intense adaptability and open source license lets you add up the required functionality. And, you can also share your innovations with others.

    System Components:

    Puppet in general is used in a client/server formation, with all your clients talking to one or more central servers. Every single client contacts the server at regular intervals i.e. every half hour, by default. It even downloads the latest configuration and makes it sure that it is in sync with the configuration. The moment it’s complete, the client is able to send a report back to the server and can also refer to the changes required.

    Following diagram displays the data flow in a usual puppet operation:

    Puppet1

    Puppet’s functionality is framed as a heap of individual layers. Each layer is duty-bound to a fixed aspect of the system with a tight control on how information transfers between these layers.

    puppet2

     

    Fig2

    How Does Puppet Work?

    The Puppet agent acts as a daemon that runs on all the client servers where configurations are required, and the servers to be managed by Puppet in the future. Now all the clients to be controlled will have puppet agent installed in their systems. This puppet agent also known as a node in Puppet will have a server designated as the Puppet master.

    Puppet Master: This machine restrains the entire configuration for different hosts, and runs as a daemon on this master server.

    Puppet Agent: This is the daemon that will run on the entire server that is to be managed with the help of Puppet. At a specific time interval, the Puppet agent will go and inquire the configuration from the puppet master server.

    Now the connection network between the puppet agent and master is built in a secure encrypted channel with the support of SSL. For example, if the Puppet agent has already applied for a necessary configuration and there are no new changes, it will do nothing. By default, the puppet agent will go and fetch the required config data from the puppet master in every 30 minutes.

    From the above diagram it is clear that puppet master server has all the configuration options available for Host 1 or Node1, Host 2 or Node 2 and Host 3 or Node 3.

     puppet3

    Following are the steps that are always followed whenever a puppet agent of any node makes up a connection between a node and a puppet master server to fetch the data.

    Step 1: Every time a client node makes a connection to the master, the master server examines the configuration to be applied to the node.

    Step 2: The Puppet master server takes and assembles all resources and configurations be applied on the node, and brings it together to make a catalog. Now, this puppet is given to the puppet agent of the node.

    Step 3: According to the catalog, the Puppet agent will apply configuration on the node and then reply. It will also submit the report of the configuration applied to the puppet master server.

    Who would find Puppet useful?

    An organization that would like to decrease the cost of maintaining its computers could benefits from using Puppet. Since the return on investment is related to several factors such as the current administrative overhead, diversity among existing computers, and cost of downtime. It might be complex for an organization to determine if it should invest in any configuration management tools, much less Puppet.

    In general, any organization should make use of server automation if any of the following are true:

    1. It comes up with a higher server administration costs
    2. Either because of contracts or opportunity cost, it pays a high price for downtime.
    3. It contains loads of servers that are fundamentally identical or nearly identical.
    4. Flexibility as well as agility is required in server configuration.

    Conclusion:

    Puppet refers to the two different things

    • The language in which code is written
    • The platform that manages infrastructure.

    Puppet is both a simple and a complex system. It is composed of several moving sections wired all together quite loosely. It is a structure that can be used for all configuration problems. Our future success rests on the structure becoming more powerful and simple, for it should be   approachable while gaining capability.