devopsy.kinsta.cloud

Tag: devops

  • Middleware360 Partners with CloudBees

    Partnership brings strength of technology along with continuous delivery & DevOps expertise to enterprise customers.

    Vancouver, British Columbia (PRWEB) January 14, 2016

    Middleware360 Solutions, experts in business automation, system integration solutions, and custom application development, today announced a services partnership with CloudBees, the Enterprise Jenkins Company and continuous delivery (CD) leader. Middleware360 Solutions will provide implementation and training services to its clients who want to adopt continuous delivery practices and are implementing the CloudBees Jenkins Platform as the foundation to do so.

    “We are pleased to be working closely with CloudBees, as they support our goal to offer clients continuous delivery solutions that are stable, scalable, flexible and fast,” said Derek Marley, CEO for Middleware360 Solutions. “The CloudBees Jenkins Platform enables enterprises to accelerate the software development process through automation, giving them the ability to build and deploy software faster, while saving time and money,” said Marley.

    The CloudBees Jenkins Platform is the industries most proven, fully featured technology platform for implementing continuous integration (CI) and continuous delivery (CD). It extends open source Jenkins with key CloudBees-developed features and capabilities that meet the unique security, scalability and manageability needs of enterprises.

    “With Jenkins adoption accelerating, strategic partners like Middleware360 are essential to delivering the enterprise-scale Jenkins solutions customers are seeking,” said Durga Sammeta, senior director of global alliances and channels, CloudBees. “We are excited to partner with Middleware360 as they are uniquely positioned in having the expertise necessary to guide customers through continuous delivery and DevOps transformations, supported by the CloudBees Jenkins Platform.”

    Offering end-to-end IT services, Middleware360 is helping clients streamline business processes, increase business flexibility, and decrease system complexity. “We are seeing more organizations looking to invest in continuous delivery as a way to seize opportunities quicker and stretch dollars further, and CloudBees helps to automate and streamline this process. Using the Jenkins platform, we are now capable of innovating in light speed bursts while remaining flexible to try different approaches to solve our client’s challenges. We look forward to many years of collaboration with CloudBees,” said Marley.

    About Middleware360 Solutions, Inc.

    Middleware360 Solutions is a dynamic full service partner focused on business automation & integration solutions, custom application development, and IT managed support that delivers accelerated results for cross-industry organizations. Middleware360 offers flexible services encompassing solutions & architecture, project delivery, and application & integration managed support. Based in Vancouver, British Columbia, we work with organizations across Canada to achieve greater business efficiency. Learn more at http://www.middleware360.com

    For more information, please contact:

    Adam Edwards

    1-844-236-0360

    info(at)middleware360(dot)com

    For the original version on PRWeb visit:http://www.prweb.com/releases/2016/01/prweb13162477.htm

  • Boston DevOps Leader Pete Cheslock Talks Accomplishments

    Boston DevOps Leader Pete Cheslock Talks Accomplishments

    Pete Cheslock began his leadership role in DevOps in 2009 at cloud-based email archiving company Sonian. The company was founded by friends and former colleagues of his, who called Cheslock for help when they got funding for the Sonian venture. He filled in wherever they needed him—as did everyone else in the first few years of the 10- to 20-person startup.

    “As we grew, I saw a need for leadership for Sonian’s five-person operations team. I went to our VP of Engineering about the need for ownership of operations and said I’d love to be the one to give it a shot,” says Cheslock.

    Sonian was an early user of Amazon Web Services, deploying production code with customers by 2008. Sonian had been named an AWS Startup Challenge finalist, but despite its forward-thinking approach to the cloud and infrastructure as code, many of its processes were immature.

    “The application had scaling issues and we were spending an inordinate amount of time on reactive measures, dealing with application downtime and using short-term fixes for continuing issues when I took over,” says Cheslock. The young DevOps shop wasn’t able to make headway in innovative, future-looking projects.

    Smothering Fires, Forging Ahead

    Cheslock transitioned its team into two groups—a proactive group for innovative projects with a view to tomorrow, and a reactive team to get the worst recurring fires under control. Cheslock added himself to the latter group while remaining head of Operations. “While we attacked the hairiest issues, the proactive group worked on tooling that we needed in support of CD (continuous development) and CI (continuous integration), which made deployments much easier,” says Cheslock.

    It had been taking the Sonian team about a week to deploy software for all its customer environments. The process of deployment affected much of the software stack; it required testing as well as completing and checking off several items on a lengthy deployment list.

    Cheslock directed the proactive team to automate much of that checklist. Soon, they had reduced deployment time to 20 customer environments in just three hours, from five three-hour periods over five days.

    Weeding Out Costly Cloud Issues

    Cheslock and Sonian next began to work on cost issues. “We built an application to analyze our Amazon usage and correlate it with our Chef server, which was our single source of truth for all instances,” says Cheslock. The app revealed unused and abandoned servers that had been used for development and testing, which were still running and costing the company money.

    “We found occasional spot instances where we could pay fractions of the retail price for batch workloads to cover these. We leveraged the Amazon Marketplace to make better purchases of infrastructure to save money,” says Cheslock.

    Cheslock was able to shrink 800 instances on a single AWS cloud with a monthly spend of $450,000 down to 400 instances across four public cloud environments with a much smaller price tag of $200,000 a month. He accomplished this in three months, even as Sonian’s cloud operations team doubled.

    Now senior director of Operations and Support at Threat Stack, Cheslock is nurturing DevOps methodologies and seeing continued growth and success there.

    BosOps

    A few years ago, Cheslock and a few friends started a Boston-area technical operations meetup called BosOps, inviting people who managed operations at various companies to get together regularly to discuss their challenges and offer support.

    “As BosOps grew, we wanted to reach a broader audience and started pulling in more people in operations or DevOps roles to gather on a quarterly basis,” says Cheslock.

    Currently, BosOps has about 150 participants, who also participate in online chats using the free tier of Slack.com, a popular team-working messaging app among DevOps folk. “It’s great for people who are new to Boston,” says Cheslock.

    BosOps helps by quickly connecting a professional network for people who are new to the industry or to the area, enabling them to meet like-minded people and to secure a better foothold—perhaps even find a job they like more than their current position.

  • Can We Stop Talking About DevOps?

    Can We Stop Talking About DevOps?

    I first heard the term “DevOps” from a friend in the software business when I was working at Dell HQ in Round Rock, Texas. He recommended I read “The Phoenix Project,” by Gene Kim, Kevin Behr and George Spafford. I did read it and I found it a fascinating story, but as a longtime network administrator (to oversimplify as much as possible) and having never been involved in developing software, I wasn’t quite sure how it applied to me.

    It was enough to pique my interest, though, and drove me to volunteer at a DevOpsDays event in Austin. Within weeks I left Dell and joined a small software company, where I could have a better chance of getting my arms around this slippery pig called DevOps and more hands-on practice with the related tools and techniques.

    So imagine my surprise when a year later, the same old friend who introduced me to DevOps suggested that the end goal of a DevOps transformation should be that we stop talking about DevOps. Uh-oh, I thought, he’s lost the plot. But he made his case by pointing out that adding testers to dev teams—a typical step in any Agile transformation—doesn’t result in new dev test or agile dev teams; they remain simply “dev teams.” Once a business/group has fully internalized the Agile or DevOps values and behaviors, he argued, “working in an Agile or DevOps way” becomes simply “working.”

    This is why many DevOps promoters, myself included, have a negative reaction to seeing “DevOps” in job titles, job descriptions or department names. While it simplifies the job of identifying which job candidates have a DevOps mindset or skill set, it effectively excuses everyone else in the organization from taking responsibility for change. “Doing DevOps” becomes the job of a particular individual, team or department, instead of a philosophy internalized by the organization.

    Of course, the horse is already out of the barn on that one. Each year we see an increase in the number of businesses advertising for DevOps engineers, forming DevOps departments or listing DevOps among the required skills for a position. It doesn’t matter whether we think this is a good thing or bad thing; evolution will take its course and there’s little we can do to stop it. What we can do is observe, acknowledge and adapt.

    Sure, the dangers are real. A DevOps department can easily become just a third silo or the DevOps engineer might become the scapegoat for everything that goes wrong between development and operations. But if a DevOps engineer, VP of DevOps or DevOps department can form, contribute to and/or nurture an environment of increased empathy, faster feedback and continual growth, that’s awesome; put the focus there. Don’t spin your wheels arguing that they just “don’t get it” or “they’re doing it wrong.”

    I’ve spent the past couple years researching, promoting and attempting to practice this thing we call DevOps. While it’s widely believed that DevOps is impossible to define, I am firmly in the camp of those who believe that empathy is, to quote Jeff Sussna, “the essence of DevOps.” Just as the sales team needs to have empathy for its customers, everyone in the value chain needs to have empathy for each other. I’m aware that many people find this term too “touchy-feely,” but the business benefit of more harmonious interaction between one’s teams and between the organization and its customers is clear: The faster and more effective one is at converting solutions into real value for customers, the more successful one will be in the market. Thus, being empathetic isn’t just being a good citizen, it’s also being a good businessperson.

    Taking it a step further, someone on Twitter recently suggested that “DevOps has nothing to do with technology.” The statement seemed ridiculous on its face. After all, the term “DevOps”—literally a portmanteau formed from the words “developers” and “operations”—was coined by Patrick Dubois, a technologist intent on improving the process of building and deploying software. But as I thought about it I started to understand. As the DevOps movement has evolved, the most fundamental components its promoters have identified, from Gene Kim’s “Three Ways” (systems thinking, amplify feedback loops, culture of continual experimentation and learning), to John Willis and Damon Edwards’ CAMS (culture, automation, measurement, sharing), to Dave Zweiback’s ICE (inclusivity, complex systems, empathy), are primarily about how people work. It doesn’t matter if one is building software or running a school—DevOps principles are sound.

    I recently tweeted the observation that “anyone who attempts to define DevOps in a paragraph is trying to sell you something,” adding, “not necessarily a bad thing, just buyer beware.” This wasn’t a criticism of tool providers—many tools, from build automation to log monitoring, are essential to an effective DevOps transformation. It was a reminder that the problems and solutions DevOps is concerned with are complex and nuanced. There is no prescribed tool set or checklist of actions one can take to be successful; an effective DevOps transformation requires thoughtful, committed action across the whole range of people, practices and products one uses in their work.

    It might take months or years of practice, but maybe one day we can all stop talking about DevOps.  

  • Only DevOps and Taxes

    Only DevOps and Taxes

    As software eats the world, it’s hard to have a conversation about anything that isn’t directly related to or driven by modern mobile, web and IoT applications. DevOps describes the modern approach to building these applications. But like all new movements, there is a cost. And while some of the costs associated with modern development are not new, it’s becoming more and more clear that DevOps organizations have to pay their tech tax or prepare for trouble.

    (more…)

  • The Role of APM in Continuous Integration and Continuous Release

    Today’s software-defined and -driven business requires fast changes in business models—a phenomenon permeating successful businesses. What this means is almost every company is learning how to make small, rapid changes and adjustments within their business, especially within software systems. As a result, IT is feeling immense pressure to evolve, and the net result is a major uptick in private cloud environments (especially Apprenda, Pivotal Cloud Foundry and Red Hat OpenShift) and public clouds (especially Amazon and Microsoft) within our install base of large enterprises. These new platforms enable faster development, testing and releasing of software.

    Enterprise customers are getting much smarter by using automation to drive the software life cycle, including continuous integration, and even experimenting with and using continuous release processes. This is no longer a startup scenario; it’s a strategy for our large, enterprise customers. These companies are trying to build agile development and operations teams by changing people, process and technology to enable a DevOps feedback loop:
    image02

    Wikipedia describes the continuous delivery loop as follows:

    DeliveryLoop

    Within this loop, application performance management (APM) can be part of build, unit, regression and load tests to drive the automated acceptance testing before new code is pushed to production. In fact, at the recent AppSphere 2015 user conference we had several great talks on this subject.

    The first talk was presented by our customer The Container Store‘s  August Azzarello, who discussed, “How The Container Store uses AppDynamics in the Development Lifecycle.” The company began with APM in production, in an effort to improve software quality before production. It began the expansion by installing APM within test, integrating it into functional and performance test suites. It also enabled alerting from dev/test so that developers and testers both understood when there were performance deviations and issues before production.

    Key features the company leveraged in pre-production included dashboards such as this one:image03

    Comparative analysis views such as this one:

    image04

    And being able to understand between releases if they were improving or degrading:

    image00

    The Container Store is using open source tools including Selenium for functional testing and Locust.io for performance testing.

    During his discussion, August also explained some of the major benefits the company saw from implementing APM in pre-production. Here are some best practices outlined by August in his discussion:

    • Monitor everything
    • Test continuously
    • Performance test early in development life cycle
    • Empower development & QA team members

    Some benefits The Container Store has seen, according to August, are:

    • Set performance expectations before production deployments – about 40 percent improvement since it started using AppDynamics in test
    • Fine-tune alert and business transaction policies prior to production deployments
    • Identify testing requirements and testing gaps
    • Decrease performance test result reporting to 20 minutes from five hours

    One of my favorite talks (which is why I selected it for the deep dive track at AppSphere) was the talk given by one of our senior sales engineers Steve Sturtevant, who came to AppDynamics from PayPal two years ago. In his talk, titled, “DevOps and Agile: AppDynamics in Continuous Integration Environments,” he explained the integration work he did. He also delved into the questions, Can you scale and auto implement monitoring in dynamic environments? Do you quantify the impact of change? Steve also offered a demo with integration between Puppet, Jenkins, ServiceNow and AppDynamics in his examples, with automation throughout the life cycle.

    One of our partners Electric Cloud specializes in continuous delivery and embraces an open ecosystem of technology providers and open source software. It has put together some great resources for people looking to explore the rest of the feedback loop:

  • Self Forgiveness

    Charlie Breaks the Build
    “How to apologize when you have broken the nightly build.” — http://bit.ly/1REOAOz

    — ROELBOB

  • From Laboratories to DevOps Factories for Continuous Testing

    From Laboratories to DevOps Factories for Continuous Testing

    The prior blog Continuous Testing and Monitoring Essentials for SDN and NFV discussed the importance and suggested practices for testing and monitoring complex systems such as software defined networks and network functions that are virtualized . Whether the product being tested is a complex network system or not, with DevOps the laboratory is no longer just a place where engineers go to test their changes. In a DevOps environment, implemented according to best practices, the laboratory is becoming an on-line operation that is reliable, usable, remotely accessible and shareable by many types of remote users that expect 24/7/365 availability.
    The old “Santa’s workshop” model of development engineering (elves) hand-crafting products in specialized local laboratories and then handing off their products to operations staff (reindeer) for infrequent delivery (on Santa’s sleigh once per year) is being replaced by a fully automated, orchestrated software DevOps laboratory infrastructure akin to a modern factory staffed by robots churning out products at a dizzy pace. Elves and reindeer need to rest between deliveries and simply can’t keep up with today’s continuous delivery expectations. Santa’s “lap-top” has become an app store where users can download products anytime no matter if they have been bad or good (but be good for goodness sake!).

    If a modern DevOps factory-style laboratory is a priority on your Christmas list, here are some suggestions for tool requirements you may want to include on your letter to Santa.

    1. Inventory tools to record and track resources:
      All of the systems used in tests such as test tools, systems under test, and interconnection systems need to be tracked in an on-line inventory database in which each resource and the critical attributes are visible and addressable by administration staff and users of the resources. The ability to discover and import new or changed resources is essential. Without these capabilities it is impossible to keep up with the continuous changes that occur as the DevOps continuous test environment evolves to meet ongoing requirements.
    2. Tools to administer users:
      With a large number of users accessing lab resources features for administration of users and user groups are essential. Large scale DevOps environments require administration of hundreds or thousands of users with varying privileges for resource access according to project priorities and schedules. The ability for lab administrators to assign privileges to individual users or user-groups is essential to control access to some resources which may be restricted for security or other reasons.
    3. Ability to create, and save test configurations:
      While tests may be created to work with a variety of configurations every test assumes something about the test configuration. In a test environment implemented according to best practices the configuration of the test, or at least an abstract version of the test configuration is specified and associated with each test. Configuration data is saved in a database and may be recalled by search attribute matches when a test needs to run.

    4. Ability to reserve tests and test configurations:
      With a large number of lab users in large scale DevOps environments and limited lab resources conflict resolution features are needed. The ability assign real resources to abstract configurations provide the flexibility to use lab resources more efficiently. The ability to reserve test resources and test configurations in advance according to a calendar, or immediately when an event trigger fires are important options to minimize wasted time for both users who may have limited time windows or automated processes that have non-deterministic schedules.

    5. Ability to orchestrate many automated tests in parallel:
      In large scale DevOps environments the number of tests that need to run in a given short DevOps cycle may vary from a few tests to thousands depending on the complexity and nature of the change that are integrated in the cycle. The tools need to be able to scale the tests and run on as many physical and virtual test resources as are available, to minimize the total time for test.

    6. Test Environment Metrics:
      The entire DevOps pipeline depends on reliable, scalable and maintainable continuous testing. Built-in metrics are essential to monitor the environment’s reliability, scalability and maintainability.

    The above is a partial list of suggestions for a state-of-the art DevOps continuous testing laboratory “factories” list. At Spirent we think continuous testing laboratory “factories” are critical for successful DevOps.

    You can read more about our views at Spirent.com/solutions/LabManagement

    What do you think of these suggestions and do you have others that should be mentioned?

    In the meantime we wish Santa, Elves and Rudolf, reindeer friends and you happy holidays and continuous happiness for the New Year!

    Santa's Workshop

  • Rugged DevOps: Good, Bad & Ugly

    Rugged DevOps: Good, Bad & Ugly

    The Good: DevOps has been a success for Dev.

    With higher expectations, better processes, more management focus and new tools like advanced PaaS and containers, developers are churning out more and more software faster than ever. Success! Or is it?

    The Bad: DevOps has been a success…for Dev.

    For Dev teams, this may result in pats on the back and high fives. But for Ops, this can look like one thankless tidal wave of work after another. The same software velocity that is praised in Dev is currently overwhelming their counterparts in Operations. And frankly, many DevOps tools released in recent years happen to benefit Dev much more than their counterparts in Ops. (My pet theory is that developers at IT automation firms are acting and thinking like…developers – focusing their creative energies on solving Dev problems.) A similar problem holds true for IT Security teams who want to build quality in by “shifting left” – see  https://devopsy.kinsta.cloud/2015/12/10/getting-rugged-devops-right/ . From the vantage point of IT Operations and Security teams, they are doing more work than ever but without any more human or IT automation resources. To add insult to injury amid their increased workloads, many IT Ops teams have to invest countless hours (away from family and personal time) in training courses and migrations to reorient their processes to fit into shiny, new Dev-centric “DevOps” tools and paradigms. 

    The Ugly.  

    Work. Overwork. Glitch. Search. Find. Rework. Repeat.

    A quick glance at IsItDownRightNow.com will show you which IT Operations teams are in a living hell at the moment. The other thing you will notice is that these IT Ops teams are from some of the most reputable companies on the planet. They are talented teams but stuck in rework cycles of web performance problems, security vulnerabilities and outages.

    These problems get the attention of everyone. Operations…and Dev…and Security…and customers…and Finance…and auditors and the press.

    No one likes rework. And no one likes the panicked fire drills that cause panicked rework. So what causes those rework cycles?

    Drama-free IT. Visibility Cures Chaos.  

    Much of this chaos can be tied to miscommunication. Boring? Maybe. Simple? No. Part of miscommunication is cultural. (Hint: OrcaConfig’s “How to Screw Up DevOps” white paper covers the cultural aspects of miscommunication). But miscommunication is also cured by automation solutions that promote transparency and visibility.

    If we want drama-free IT we need IT automation solutions that eliminate miscommunication and missed assumptions between Dev, Ops and Security.

    What better way to do this than with full transparency and visibility?

    Bird’s Eye Views:

    Many IT automation tools cater to SysAdmins who are interested in managing configurations of individual servers. That’s great if your focus is on individual severs. But IT Operations, eCommerce teams, Application Owners, Compliance & Security teams and IT Managers often care more about the health and performance of their application ecosystem (including related applications, middleware, databases and configurations that tie them together). So there is often a mismatch between the tools that SysAdmins and Developers have versus what IT Ops needs.

    Operating at Enterprise Scale Requires at-a-glance Visibility:

    IT Ops teams need bird’s-eye views of applications, databases, middleware and ecosystems to promote ease of ongoing operation. They need to be able to see, at a glance that a configuration compliance problem exists and they need to know right away the location and nature of the error. Large scale IT Ops teams do not have the luxury of toggling back and forth between multiple reports and multiple screens searching for that non-compliant, broken needle in an ecosystem haystack. If they are faced with a glitch or an outage, they need to find and fix it right away. One size does not fit all. Dev, Ops and Security each have their own interests and their own need to view their application through a lens that is most meaningful for them. Multiple ecosystem views eliminate guesswork between Dev, Ops and Security and save precious time in the find-fix cycle.

    Forrester Research spells it out well in their 7 Habits of Rugged DevOps white paper, Habit 1: Increase Trust And Transparency Between Dev, Sec, And Ops:

    “I&O pros pride themselves on understanding the interconnectedness of the hardware and software environment, and they are unnerved by complexities that poorly governed delivery practices create because the firm rates I&O pros on their ability to improve the performance and stability of the production environment. To maintain the environment, they must reduce the chances of an outage or interruption of service, and they must reduce the MTTR when an issue does occur.“

    Understanding that interconnectedness depends greatly on how much intuitive ecosystem visibility we provide to our colleagues in IT Operations. But it’s not just IT Ops that benefits from visibility, Dev and Security do too.

    Developers are able to write more secure code when they get early, in-context feedback. As David Mortman, distinguished engineer and Dell chief security architect, said, “Security issues are product quality issues, and no one wants to write buggy code.”

    Even better than efficiently finding and fixing errors is of course to prevent them in the first place and to proactively eliminate the damage they cause. Here too, the answer is better visibility. With true application ecosystem visibility, Dev and Ops teams would be able to model relationships between applications, middleware and their configurations so users will know that “changing this, affects that”.

    My teenage son has better visibility via his smartphone as to his driving route and weather conditions than I have for my multibillion dollar IT operation.

    Visibility into the Future:

    Ecosystem visibility is a key to communicating between Dev, Ops and Security and running complex application environments in the present. But what about the future?

    Release automation tools and custom scripts are excellent at deploying changes across large environments. Unfortunately they can be just as efficient at deploying typos and other mistakes across large environments, causing the chaos that we discussed earlier. Here again Operations teams would benefit from improved visibility – the ability to preview and pre-validate proposed changes across the entire ecosystem well before those changes are deployed. This is the real promise and savings of ecosystem visibility. Better visibility, with more use-case lenses cuts out the miscommunication that causes too many performance glitches, security vulnerabilities and outages. This chaos takes a toll on our IT Operations teams, our employers and our customers.

    What Next?

    We are soon entering a new season with new budgets. The temptation to “buy something” will be great. In the spirit of Rugged DevOps my recommendation is to take a full, bird’s eye view of your SDLC and to shift Ops and Security leftwards, building their critical considerations into your processes and into your IT automation tool selection.

  • Never Mind the Bollocks, Here’s the DevOps

    Never Mind the Bollocks, Here’s the DevOps

    What is DevOps?

    “DevOps is a cultural and professional movement” –Adam Jacob

    [movement (n): a group of people working together to advance their ideas.]

    So, who are these people and what’s the big idea?

    The people are system administrators, developers, product managers, QA technicians, security analysts, network engineers, and anyone else involved in the business of developing software.

    The big idea is to increase the value your product or service delivers, more quickly with less effort.

    (Having a product or service that is designed and built well isn’t inherently valuable. The value comes when your customer is able to use your product or service to solve a problem. DevOps is all about delivering value quickly and effortlessly.)

    DevOps practices and technologies are evolving, but here are some of the core concepts paraphrased–be sure to read the links in the footnotes for the full explanations:

    The Three Ways

    • Systems Thinking
      • Learning how everything is interconnected, from concept to customer
    • Amplifying Feedback Loops
      • Cutting the time between action and reaction, failure and success
    • Culture of Continuous Experimentation and Learning
      • Recognizing failure is important data about how and where to improve

    CAMS

    • Culture
      • It’s about how people relate and work, not something you can buy
    • Automation
      • Faster, less error-prone processes help amplify feedback loops
    • Measurement
      • You can’t get where you want to be until you know where you are
    • Sharing
      • Effective teamwork ignores organizational boundaries

    ICE

    • Inclusivity
      • Everyone is responsible for (and benefits from) these practices
    • Complex Systems
      • Because simple systems are simple
    • Empathy
      • Real collaboration requires real understanding of another’s point of view

    That’s the theory from a very high level; the following Q&A provides some broad explanations of related concepts. These are actual questions I was asked in a recent discussion of DevOps.

    Q: What specific skills or experience do I need before I can put “DevOps” on my resume?

    A: It depends. At this point in time when recruiters and/or hiring managers list DevOps in a job posting they are almost always looking for a “DevOps Engineer” (i.e. a sysadmin who knows just enough coding to be dangerous), or a “full-stack developer” (i.e. a developer who knows just enough about system management to be dangerous). The reality is that (as of today) there is no DevOps certification, organization or even manifesto, so anyone who pretends to authority on what is and isn’t DevOps is overstating their case at best, a charlatan at worst.  

    Q: What is source control?

    A: Source control is a repository for files that make up a modern software application during development. It maintains a historical record of changes so it’s easy to review (or rollback to) changes made to an application’s source files. The most popular source control technology today is Git, and GitHub is one of many online services used to manage Git repositories.

    Q: What is Jenkins?

    A: Jenkins is to task engines or “build servers” what Kleenex™ is to facial tissue. It’s currently the most widely used software product for automating various functions of software build and deployment. For example, a system might be configured such that any code change pushed to source control triggers a job in Jenkins to build, test and deploy that code.

    Q: What is configuration management (e.g. Salt, Ansible, Puppet, Chef)?

    A: Configuration management is a means of scripting server configurations so it’s easier to track, deploy or make configuration changes to large groups of systems.

    Q: What are containers?

    A: In the same way that server virtualization allows you to have many isolated “virtual machines” on a single physical machine, container technology allows you to have many isolated application environments on a single operating system. Containers have been around in Unix/Linux for a long time, they just boomed in popularity when Docker came along and made them easy to use. The next version of Microsoft Windows Server (2016) will introduce Windows containers.

    Q: What are microservices?

    A: Microservices are small, independent components of a software application that are built, tested and operated in isolation from the core product. Using microservices enables development to be faster and more nimble than possible when working with a large, monolithic application.

    Q: What is Continuous Integration/Delivery/Deployment?

    A: Continuous Integration is the practice of continuously integrating (and testing) new code with your existing source code. Continuous Delivery is the practice of automating as much of the build/test/release process as possible while still requiring a manual push to production. Continuous Deployment is the practice of fully automating build/test/release all the way into production.

    Q: Are there any conferences or meetups I can attend to learn more?

    A: Yes! The original DevOps conference is DevOpsDays and there are many of these events around the world annually. A popular conference with large enterprises is the DevOps Enterpise Summit.  Various DevOps-related meetups (#CoffeeOps on Twitter) are springing up around the country. Check the CoffeeOps.org website for details, or search for DevOps at Meetup.com.

    Q: [Do I need to understand everything above | Is this all I need] to be or do DevOps?

    A: Absolutely not, on both counts. You can successfully implement a DevOps way of thinking/working by incorporating all or just some of the above, and there are many other tools and practices around delivering value more efficiently. Naturally there are extensive resources available (a few linked in the footnotes) to do a much deeper dive on all these subjects.  

  • An obituary to a Managed Test Service

    An obituary to a Managed Test Service

    1st October 2020, Enterpirseborough , F500 Inc street

    Managed Test Service, 66, died Friday, 3rd October, 2020 at the Delivery governance war room in the IT head quarters of F500 inc. following a terminal illness caused by a lifetime burden of 34 SLA’s, debt burden of 44 KPIs , 29 painful claw backs by procurement due to failed deliveries and overdose of turnaround specialists and consultants

    MTS leaves 4 programs , 45 projects, 12 application centres and a number of small changes behind.Born and raised in the HQ , MTS was a lifelong resident of the borough.

    In the early years, MTS would help do functional testing for the core system portfolio and eventually taking ownership of non-functional testing and user testing. After graduating from the delivery transformation high school , MTS attended the SLA University, graduating with a degree in cost optimisation and skill super-speciaisation. MTS eventually joined the IT Board, where he was the voice of quality(or so he believed)

    His attention to detail and obsession with centralisation of anything that had Test in it’s name was legendary. He was proud and preached the virtues of , albeit bloated and inflexible, test service

    However,he struggled with newer delivery approaches of Agile and DevOps which spread like cancer throughout the delivery organisation. Devops challenged the fundamental idea of skill super-specialisation and independent testing that MTS championed and built his empire on. DevOps challenged the way of living of MTS as unsustainable 

    DevOps valued people and interactions over process unlike MTS which obsessed about process

    DevOps valued working software while MTS was worried about comprehensive documentation

    MTS got caught up in time-wasting contract negotiations instead of allowing his team to focus on customer collaboration

    MTS preferred a predictable plan while his delivery friends had already moved on with adaptable plans

    A funeral service was held on Monday 6th October from the funeral Home of Procurement , with a private burial.