devopsy.kinsta.cloud

Tag: it

  • Why Your Manager Will Want to Send You to Jenkins World 2017

    Why Your Manager Will Want to Send You to Jenkins World 2017

    Jenkins World 2017 is right around the corner. The conference will be held in San Francisco Aug. 28-31 and will be the biggest event of the year for Jenkins users, with approximately 2,000 people expected to be in attendance! You will not want to miss out on this event, full of learning and networking opportunities.

    Need some help convincing your manager why you should attend? No problem—we have laid out all the reasons why attending would be beneficial to you and your company. Once you have convinced your manager to attend, don’t forget to register today! (As a media sponsor for Jenkins World, we are providing a special offer for our readers. Register with this promotional code and get 20 percent off your registration: JWDEVOPSCUST.

    Educational Value

    Jenkins World will be offering more than 60 educational sessions given by real Jenkins experts—a chance to learn from the most experienced users. Did we mention that you can also receive a free Jenkins exam with the purchase of a full conference registration? Imagine the benefits for both your résumé and team.

    At the conference, you’ll be able to take advantage of great training sessions to better enhance your Jenkins capabilities. The training sessions include Jenkins Certification Training, Introduction to Jenkins, DevOps Leader Certification Training and DevOps Test Engineering Certification Training. We recommend highlighting to your manager what sessions you will want to attend in advance. Check out the full agenda here.

    Jenkins World is offering keynotes from many industry leaders. Be sure to emphasize to your manager the importance of hearing from the very best in the Jenkins community, live on stage and in the breakout sessions. From Jenkins founder Kohsuke Kawaguchi to CloudBees CEO Sacha Labourey and featured speaker Jez Humble, your manager will greatly appreciate the knowledge you bring back to the office from listening to such experienced industry experts.

    Networking Opportunities 

    The Jenkins World conference will provide numerous networking opportunities. Learn what similar problems and challenges other organizations are facing in the industry. Make it known to your manager that you will be exposed to people like you, with like business needs and challenges, that you will be able to connect with.

    Prove ROI

    When convincing your manager to let you attend, it is first important to make them aware of the potential ROI of this opportunity. Detail exactly your expenses including airfare, hotels and meals. This will better help your manager understand the exact cost to send you to Jenkins World. Make sure you also present how this knowledge will help push you and your team forward, ultimately propelling your entire organization forward. The ROI will be evident – make that clear! (And the ROI just got better, because devopsy.kinsta.cloud readers can use this discount code and get 20 percent off: JWDEVOPSCUST.)

    We hope this provides enough information to help you convince your manager to let you attend! We have also created an email template to use when sending all this over to your manager for review. Once you have successfully convinced your boss, go register!

    — Alan Shimel

  • Achieving True Automation is a Marathon, Not a Sprint

    Achieving True Automation is a Marathon, Not a Sprint

    But It Starts in the Cloud

    Arguably, the most important goals for companies seeking to get into cloud today are agility and flexibility to innovate at speed and scale. Adding cost savings to the mix makes the possibilities all the more attractive. And these three pillars can only be achieved with automation.

    But while many companies may believe they’re automating (and thus attaining these three goals), they’re really not. In the rush to cloud adoption, they fail to see that this type of investment takes time and work—a lot of work. Think of it as a marathon, not a sprint.

    While it’s a significant step toward achieving scale and speed, simply moving an application to cloud is not enough to attain true automation. Adding genuine automation to your server means enabling it to spin up or down as needed, react to scaling requests and shut down when not in use. Only when these processes are in place can you then start seeing the cost savings and agility promised by cloud.

    While there is no simple road map to achieving true, seamless automation (near-Nirvana), there are clear and well-worn steps that organizations seeking these goals can take. Looking at it from a broad perspective, automation in the cloud depends on two major initiatives.

    Long-Term Value is in App Automation

    The first step is to figure out where automation will provide the most value (from an application perspective). In most cases, at least as far as what we’re seeing across the marketplace, the answer to this will likely revolve around infrastructure.

    The second step gets a bit trickier. You essentially want to connect automation to the applications themselves (replacing the manual task of writing a script). The challenge then becomes pulling the application back into the larger architectural context so that it can respond to an event without human intervention. This phase involves making the application cloud-ready—that is, furnishing it with the ability to trigger automation without someone sitting at the controls.

    This second phase bears closer scrutiny—it’s here that the people on the ground start to lose faith, because with some applications automation may seem all but impossible. Let’s face it: A fair majority of applications were not designed with automation in mind. Legacy applications in particular (which typically constitute the bulk of most companies’ IT estate) are fairly fussy when it comes to automation. This is when organizations start debating the value of opening code and making changes—whether the investment of time and capital is really worth it.

    Which brings us to the two biggest barriers to automation—costs and culture. Yes, it can be expensive to implement the processes and skills to achieve game-changing automation in the short-term. It requires moving application development specialists to new roles, a massive shift in culture and skill sets within IT. This is particularly true for code development, which has been manually focused for so long. Many companies fail because they don’t see automation as an ongoing true software development program (which, of course, it is).

    Attaining DevOps

    The Holy Grail of automation is achieving a seamless Development-Operations environment (DevOps), one in which software developers and the IT folks are continuously collaborating and communicating to automate software delivery and infrastructure changes. One of the chief goals of DevOps is to create a culture and environment where building, testing and releasing software happen frequently, rapidly and reliably.

    Achieving a true DevOps environment means that you are a functioning automated shop. Automation does not end with the first deployment. In fact, it is only the beginning. You will continually face new upgrades and changes in service, requiring near-constant tweaking. But automation smoothes the process, loosening the friction of life cycle management. Automation becomes embedded into the very fabric of your entire IT estate.

    For some companies (mostly startups), automation is not a luxury but a necessity. Look at Netflix (which, in some respects is less of a startup and more of an established player). The only way the company could scale and stabilize to meet customer demand with the success it has over the past few years was to automate. It would be physically impossible for Netflix to serve its customers any other way.

    Same with Amazon. Jeff Bezos figured out early on the value of automation in the cloud and built the flexibility into Amazon’s infrastructure to grow and scale according to exponential customer expansion.

    We’re seeing this happen increasingly across industries—from the financial sector to the healthcare industry.

    One large global financial institution is changing its very culture by putting automation at the very core of everything it does, from loan applications to payroll. It has taken the bold step of only adopting applications that can be automated. The simple rule of thumb here is, “If we can’t automate it, we’re not going to do it.” This has resulted in the financial institution being able to provide an improved customer experience, providing features for customization of services via their mobile banking app.

    Another is Avalon Healthcare Solutions, a laboratory benefit management company. The organization wanted to accelerate service delivery with a 100 percent cloud-based claims editor. So it developed a portal for providers, patients and health plans to offer appropriate access to data, claims and prior authorization. Avalon can now edit from 28,000 to 38,500 per hour in a single environment with 99.99 percent uptime and 99.95 percent accuracy,

    The lessons here are clear. By pacing their race with an eye for the long-term goal, Avalon, Amazon and Netflix—among others—trailblazers across industries, are reaping the benefits cloud-automation offers. Namely, they are scaling, becoming more agile, innovating and delighting their customers all at the same time.

    About the Author / Chris Wegmann

    Chris Wegmann is Managing director for Amazon Web Services Practice & Relationship lead, responsible for helping Accenture cross-industry enterprise clients leverage the power of Amazon Web Services including through the Accenture Cloud Platform. He has 20 years of experience in technology consulting and specialization in technical architecture, infrastructure design and engineering, legacy system migrations, cloud application architectures and systems operation. Connect with him on LinkedIn and Twitter.

  • How IT is More Like an ATV Than a Sedan

    How IT is More Like an ATV Than a Sedan

    There is an analogy for IT being like a car and it often goes something like this:

    IT should run like a well-oiled machine. I don’t get in my car and think about how it works, I just work some controls and it does what I need it to and it goes where I need it to go. No assembly required!”

    When people think IT, it seems they’re hoping for their IT department to work like a Tesla luxury sedan that drives for you. They like to think of IT in this “it should just work” kind of mentality. The internal dialogue of some may be, “I have this goal, IT is this tool to get it done, and I have paid for it! It should just work by itself! Heaven knows, I have spent enough on it!” They want something that’s comfortable, doesn’t require much interaction and gets them where they need to be.

    The problem with the sedan metaphor is that sedans are not really what companies need.

    Sedans are built for paved roads, made to go to places that others often go. The average sedan can’t really explore much else other than what is well-paved and well-traveled by others. They’re a comfortable ride for drivers who want all the amenities of the home wherever they are. Anything too far off of the beaten path and the car is being torn to pieces by the rough terrain. Sedans perform consistently and reliably in consistent and reliable environments.

    This is not to say that IT should not be reliable. By all means, IT has to be reliable. If IT isn’t operating reliably, much like a broken car it should either be fixed or replaced. Why would anyone pay for something that can’t perform the tasks you need it to do?

    However, organizations know they have to take calculated risks, and the larger the risk, the larger the payout. This means going into unfamiliar territory and going down paths that are not mapped out. Even a Tesla is going to struggle over terrain that isn’t already mapped out.

    On top of that, we know customers and technologies are constantly changing. There is very little consistency from the world outside of the enterprise. Every day brings new fluctuations and challenges that companies need to anticipate and adjust to.

    So why do we expect IT to behave in a consistent way when the environment around us is constantly shifting? We can’t act as though our business can succeed riding around in a comfortable sedan! We need something that can be flexible and can still move us forward.

    Think ATV, Not Sedan

    The ATV fits this kind of unpredictability perfectly. ATVs can adjust to a variety of terrain. They don’t need paved roads nor beaten paths. They can go almost anywhere and can get there quickly. These machines are rugged; they can adjust to a variety of terrain and, most importantly, they can go anywhere—if the driver knows what they’re doing.

    But ATVs are not comfortable. An ATV takes knowledge to drive and it takes engagement. One can’t sit back disengaged and hope to have a smooth ride on an ATV that is going full speed. The places these machines are made to go are not for the complacent or for those seeking comfort.

    The business-IT relationship should look more like an autocross driver and his ATV than a suit in a Lexus. In this analogy, both machine and driver are adjusting in unison to the environment around them. The driver (the business) guiding the ATV (IT)  where to go and pushing through hills, mud and dirt to make sure both arrive safely and quickly despite the dangerous and uncertain environment around them. At the end, the driver and his machine will have pioneered places many feared to tread and will be rewarded appropriately.

    To extend the analogy, this is not a problem only between business and IT; this is the same attitude Dev often takes with Ops. Dev says, “Here’s a build, your environments should be good enough,” and Ops is expected to just make it work. Isn’t this the same disconnect as the IT and the business?

    It is so important to collaborate in a large enterprise. It takes investment of not just money but also time. If we have an agile team with no product owner, we essentially have a car with no driver. If we have Devs who don’t talk Ops, don’t we have a car body with no engine?

    In today’s world of Agile and DevOps, the companies that build that bridges between Devs, Ops and the business are the ones who take the calculated risks and succeed. These companies win bigger market shares and know confidently what their customers need. They can experiment fast with different business ideas, use the latest and the greatest technology and not comprise on security. These same companies can leverage their IT function to accurately monitor spending while minimizing waste.

    When businesses interact with IT, they shouldn’t just toss something at them like an external vendor and expect quality. Collaboration and engagement is the key. When all the necessary members in an organization are talking, communicating and engaged with one another, then we begin to see the true power of IT.

    The power of IT is the ability to go over terrain that would destroy other organizations. It is the ability to set any vision and know that your people will have the tools to tackle whatever comes their way. It is the ability to adapt, change and continuously improve while watching organizational goals become reality.

    About the Author / Caleb Wolfe

    Caleb is an IT professional with a passion for DevOps and transforming the way IT organizations work. As a member of Delta Air Lines, Caleb has a variety of experience from working as a baggage handler, business analyst, software developer and as a technical analyst in IT transformation. Caleb uses his multidiscipline experience to identify and remove constraints, create effective throughput and work to break down barriers both internally and externally. Caleb is a perpetual student of process improvement and IT technology and uses his knowledge for the betterment of Delta’s employees and customers worldwide.

  • When IT Disaster Strikes, Part 2: Who You Gonna Call?

    When IT Disaster Strikes, Part 2: Who You Gonna Call?

    In Part One of this series, I provided a high-level overview of what an efficient incident response process entails from start to finish, including general framework for an incident response team. Now let’s delve a bit deeper into the role each person plays.

    In my experience, there are several core people who make up an effective incident response team. Regardless of the severity of an issue, it’s all about coming together, working through the problem and finding a solution quickly before the incident has a severe impact on your end users. Below is a breakdown of the most critical roles.

    Incident Response Structure

    The Incident Commander

    The Incident Commander (IC) runs the entire incident response process and acts as the single source of truth for what’s currently happening—as well as what’s going to happen—during a major incident. His or her primary responsibility is to drive the incident toward resolution.

    To start, the IC is responsible for helping teams prepare by establishing agreed-upon communication channels and training team members on best practices and procedures for communicating. When an incident occurs, the IC has to move quickly to jump-start the resolution process, getting everyone on the same communication channel and collecting pertinent information from each team member. After getting a sense of the situation and the plan of action to make the necessary repairs, the IC must delegate all repair actions and continue to stay abreast of updates to drive the team toward resolution and be a reliable authority on the system status for all stakeholders. Throughout the process, the IC is not responsible for taking repair actions; rather, the IC ensures they are assigned to the appropriate people.

    Following an incident, the IC assigns the post-mortem to an appropriate owner to help determine what went wrong and how it can be avoided in the future, as well as areas of improvement for the incident response team. This process includes creating a template immediately following the incident for team members to add their thoughts while still fresh, assigning the post-mortem after the event is over, and working with team leads to schedule preventive actions.

    So what makes a good IC? At a minimum, ICs should possess the following traits and skills: excellent verbal and written communication; high-level knowledge of how different services interact with each other (and their business impact); and the ability to assess the effectiveness of various tactics/strategies, make rapid decisions on courses of action and modify plans on the fly as necessary. The final, and possibly most important, characteristic ICs should have is gravitas. A good IC is not afraid to take command and get things done. He or she must be willing to kick people off a call to remove distractions—even if it’s an executive.

    The Deputy

    The Deputy is a direct support role for the IC. Deputies are expected to perform important tasks during an incident and should be trained as an IC as they may have to take over command at a moment’s notice. The deputy is expected to support the IC in a variety of ways, including bringing up issues the IC may not have noticed, such as keeping an eye on timers that have been started or circling back around on missed items. Deputies also act as a “hot standby” IC. Being an IC can be a cognitively draining role, and it’s good to “cycle out” during longer running incidents.

    Deputies’ responsibilities can vary, ranging from paging the right on-call engineers to managing the incident communication channels. They also can be in charge of contacting stakeholders to provide status updates from the IC. Deputies should be deeply familiar with incident response protocol, and possess organizational skills that keep things on track to allow the IC to focus on the incident.

    The Scribe

    Scribes are responsible for documenting the timeline of an incident as it progresses, making sure all important decisions and data are captured for later review. While the IC focuses on the problem at hand, it is critical for the scribe to capture an accurate timeline of events as they happen. This timeline will later be reviewed and analyzed during the post-mortem to determine how well the incident response team performed, and any additional impact that might not have been noticed at the time of the incident.

    In addition to recording any oral communication regarding the incident, the scribe must keep track of important data, events and actions as they happen via whatever channel of communication has been designated by the IC (Slack, email, etc.). Specific details the scribe should note include key actions as they are taken, status reports when one is provided by the IC and any key callouts during the call or at the ending review.

    Subject Matter Experts

    Subject Matter Experts (SMEs), sometimes called “resolvers,” are domain experts or designated owners of a component or service that is part of an organization’s software stack. When there is a problem with a service, an expert is needed to be able to quickly help the IC and deputy identify and fix issues.

    Typically the primary-on call at the time, the SME should be able to diagnose common problems with a given service, rapidly fix the issues found during an incident and concisely communicate the following in a report:

    Condition: What is the current state of the service? Is it healthy or not?

    Actions: What actions need to be taken if the service is not in a healthy state?

    Needs: What support does the resolver need to perform an action?

    The Customer Liaison

    Those of us in the technical weeds have a tendency to overlook the impact our work has on customers and our organization’s bottom line. The customer liaison is an important member of the team, as he or she is responsible for interacting with external stakeholders to keep them up to date on any IT incidents that may impact them. The customer liaison is typically a member of your customer support team and handles all outward communication, including one-on-one interactions, publicly facing updates on Twitter or StatusPage and the external message from the completed post-mortem. He or she also should relay any customer feedback to the IC throughout the incident response process.

    At a minimum, these are the roles that are vital to swift incident resolution. In future articles, I will break down details of the specific training involved for each of these roles, as well as specific examples of how I’ve seen them work together to resolve IT issues.

    About the Author / Eric Sigler

    Eric Sigler is the Head of DevOps at PagerDuty, helping protect its customers from the pains of downtime. Before his current role, Eric led infrastructure teams at Minted, Expensify, and the Missouri University of Science and Technology. Connect with him on Twitter.

  • In DevOps, Speed Isn’t Always the Point

    In DevOps, Speed Isn’t Always the Point

    The high-tech industry has fallen into a rut and seems to be struggling to get out of it. This rut is most fervently seen when talking about DevOps, but it exists across the board.

    We’ve fallen in love with the idea that faster is always better. That idea is provably false, and the assumption that everything needs to be faster is false, also.

    Early on, time to market and increased responsiveness to user needs were the driving market differentiators for agile development, DevOps and DevOps tools. There were indeed cases where IT was not responsive enough to business needs—I think most of us were acutely aware of this issue, so dwelling there for a while was not a terrible thing. But responsiveness to business needs is one piece of a much larger puzzle. And we seem to be stuck, with some lip service paid to other strengths of DevOps … as long as it’s still delivered yesterday.

    In my career I’ve worked in two industries where speed of delivery was a tertiary concern for core business systems. To be blunt, when you are putting together a system that will administer contracts expected to last a hundred years or more, you really don’t get that worked up about it being out there tomorrow and “good enough,” you worry about it being right when it does go out, so you’re not still paying for mistakes a century from now that were made by rushing today.

    Of course, there are vendors that don’t want to hear people like me say these things. Of course, there are products with other benefits that are more important than speed of delivery. But as an industry, we’re still too obsessed with speed.

    How we too often see priorities

    Most industries do not even fall into a neat category where they are all or nothing. For most, some teams need to be fast, using agile, CI/CD and fully automated deployment to drive out changes fast (not as fast as some talk—most don’t even need weekly, but fast, nonetheless), while other teams need to be more thorough and cautious and the cadence of releases really doesn’t matter as much as the final result.

    So my advice is similar to advice I’ve offered on similar “hot” topics for the last decade or so:

    You are the rock stars.

    No vendor, analyst, pundit or author knows your vertical market, organization, environment or team the way you do. Do not let them proxy their view of what is “right” over you. Yes, far too many act as though, “If you’re not doing X, you’re behind.” But again, you can look at your industry and get a better grasp of what the definition of “behind” is than someone talking in generalities.

    Know what you need, know what is most important, know how to get to what you need. Don’t do what “everyone” says you should.

    But don’t dismiss the need, either. There are other benefits to these technologies that we have only recently started discussing. Infrastructure as code is an astounding way to transfer knowledge should something happen to critical people, for example. You just have to choose the technologies for the right reasons, and what the right reasons are is dependent upon the organization, not what Vendor Y is selling today.

    We’ve come a long way, and are on the cusp of some very cool stuff, but make sure you know what you need, and how to get it, then keep doing your magic.

    — Don Macvittie

  • Automation’s Impact on a Structured Life

    Automation’s Impact on a Structured Life

    A few years back my sister’s husband died after an unexpected illness. My sister, who was in her early 50s, experienced a devastating loss at a relatively early age. To her good fortune, my brother-in-law left behind an adequate pension and their mortgage had been paid off, so she didn’t have to bear the burden of having to work to make ends meet. And she didn’t—for a while, anyway.

    After a period of mourning and adjustment, however, my sister decided to return to work. I asked her why, and this was her response: “There were only so many movies I could go to, only so many TV shows to watch, only so many trips to take. I just needed something to do.”

    Now you may ask, what does my sister’s loss have to do with the impact of automation on human employment? Consider this: As automation replaces more human labor, fewer people will be required to make the economy function. Many of those whose labor is no longer needed will be left unemployed, sitting at home deprived of the thing that gave their lives meaning and structure: a job. And without a job, many will be left adrift—not just economically, but also psychologically, living a life without meaning or purpose. That which made their lives worth living will be gone. The implications of a population put aside by automation and living a life without structure or meaning are significant.

    Allow me to elaborate.

    The Need for Structure in Day-to-Day Living

    Human beings are not born with the instinct to organize their waking hours. Anybody who has a 2-year-old can tell you, a child will run around all day until he or she drops. It’s up to mom or dad to say, “It’s time for breakfast, “It’s time for lunch,” “It’s time for a nap,” “Bedtime’s coming; put on your pajamas and let me read you a story. Good night.”

    Children need structure imposed on them from an external source. That’s how it is. This role is filled by a parent, and later in life the school in the form of structured activities performed at usual times. By the time a youngster enters high school, most will have a firm sense of how a day is organized.

    This sense of organization transfers well to the workplace: A good employee respects the structure of the day. She arrives on time, does the tasks for which she is responsible, communicates the status of her tasks, respects the time of others and meets the time demands made upon her. Whether you work in a factory or a law office, being able to operate effectively within the structure of the workday is essential to one’s economic and psychological well-being. There is a certain comfort that comes from knowing where one is going to be on Tuesday and knowing what one will be doing.

    So, what happens when the job goes away? How does one organize himself or herself without something explicit to do? As my sister said, “There are only so many TV shows to watch.”

    Let’s take a look at the extreme.

    Providing Structure Where None Exists

    When I was a young man, before I got into programming, I was a counselor at a secure detention facility for adolescent boys. This a nice way of saying I was a guard in a kiddie jail. Most of my day was spent supervising the movement of teenagers who had committed very serious crimes. When I say supervising their movement, I mean that in the most literal sense. The job of my squad was to make sure the residents woke up on time, dressed in their rooms and were ready to go to school. Then, we called for lineup. The boys lined up and were counted. After count, our squad moved the line to breakfast and then onto the facility’s school. Once in school, we stood at the back of the classrooms to supervise the residents. If a student acted out, we removed him from class. At the end of the school day, we did the lineup again and went back upstairs. The residents went to their rooms. Then they lined up for the exercise yard. At 6 p.m. we lined them up again and went to dinner. After dinner, we moved the line upstairs. At shower time, we moved the line to the shower room. The day was very structured, to say the least. Day in and day out, everyday was predictably the same.

    And you know what? It worked.

    The residents responded to the structure. Most grew to accept the routine. They went to school and got a little smarter. Three square meals a day made them a little healthier. These were boys who had been left to their own devices since early on, mostly because of neglect. They had little sense of how to organize a day. They just did whatever popped into their heads. And sometime what popped into their heads was an armed robbery or felonious assault. In terms of the ability to organize themselves, most were at the level of a 2-year-old—a scared 2-year-old. Not surprisingly, the predictability of events and presence of supervision made them feel safe. Once, I asked one of the residents why he was there. He said with surprising candor, “Because I want to be.”

    When a Job Goes Away

    Granted, adolescent incarceration is an extreme example of imposing structure on someone’s life where no structure exists. But, what happens to a person when a job—the basic agent for organizing one’s daily life—goes away?

    Here’s what happens.

    Some people die prematurely. A study of Shell employees found that those who retire at 55 are 89 percent are more likely to die in the 10 years after retirement than those who retire at 65.

    Others have increased rates of substance abuse. A study conducted by the Substance Abuse and Mental Health Services Administration indicates that 17 percent of unemployed worker suffer from substance abuse—twice that of those who are employed.

    Or, they spend more time sleeping and watching TV, as reported by the Wall Street Journal.

    Clearly, having a job is better than not having a job. Financial considerations aside, it’s the way by which most people organize their day. As more people become displaced from the workforce because of automated labor and are living without the demands of daily work to structure a day, more of the population will feel adrift. If the trends described above stay true, there will be an increase in substance abuse, TV watching and death rates. They also may look to other external forces for structure, such as political movements that promote order, rank and predictability.

    So, what are we to do? In earlier versions of this article, I included a call to action to revamp, maybe even revert, the educational system to focus more on the arts and humanities rather than the baseline skills required to get a job. I planned to point out that artists, athletes, scientists and entrepreneurs don’t need to a job to structure themselves. They always have something to do. They have an internal ability to organize themselves in the pursuit of short- and long-term goals that are their own. As we move toward full automation, these folks are going to do just fine.

    Anyway, that’s what I planned to propose in the earlier versions. Now I just don’t know. I am not sure we have the social or political will to address the problems that are on the horizon. The highly educated people who have good analytics skills and a creative outlook will find paying employment. But, as trends indicate, those who are paid to follow instructions and perform redundant tasks will be replaced by robotic automation. They will go home. They will watch unlimited amounts of movies and TV on Netflix, Amazon and YouTube. They will play games on the internet, for a while anyway. Then, one day they will come to realize that there are only so many movies to watch and so many games to play. The appeal of an unstructured life will wane. They will want something to do and have no idea about how to make that something happen.

    So the questions at hand are these: Will we fortunate ones—particularly those of us in IT, the people who are implementing the automation—watch from the sidelines? Or, will we come to understand the consequences of automation on human employment—and in doing so, will we be become part of the large-scale solution, devising ways that help those that are going to be displaced think different and be different?

    I hope so.

     

    This article is the last of the series, The Impact of Automation on Human Employment. Here is a list of the previous articles:

    What Do We Do When Everything is Automated

    Rethinking Unemployment in the Age of Automation

    The Impact of Automation: Considering 3 Facts

     

    — Bob Reselman

  • Infographic: DevOps Lessons from Lean Auto Manufacturing

    Infographic: DevOps Lessons from Lean Auto Manufacturing

    Lean principles are as relevant to software delivery today as they were to auto manufacturing in the 20th century. And when you apply lean practices to software delivery, you get the same great results — lower costs, faster cycle times and higher quality.
    See the below infographic from Puppet to explore what software can learn from lean auto manufacturing, including the role DevOps practices and continuous delivery play in improving organizational performance, productivity and profitability.

     

  • Digital Business: Paving the Way for DevOps’ Second Act

    Digital Business: Paving the Way for DevOps’ Second Act

    DevOps is the buzzword of the moment. It’s at the heart of every strategy—not just CIOs’ IT transformation strategies but also IT vendors’ sales and marketing strategies. The question business unit leaders always ask is, “Is DevOps to improve IT or to boost the business?”

    The disconnect is so big between the concerns of today’s DevOps practitioners and business unit expectations on one side and digital competitive challenges on the other that the question is worth asking. Indeed, the proliferation of tech startups and digital services is making competition tougher and forcing business unit leaders to adopt innovation, velocity and timely revenue as their top competitive advantages, helping them to survive their industry disruption and then boost their digital growth.

    Let’s say it straight: The many DevOps and even cloud migration projects out there aren’t likely to help business units effectively address the digital economy’s challenges. Automating your application deployment processes with infrastructure as code and continuous delivery infrastructure on their own will never make your company an innovation champion or equip it with the fastest time-to-value in the world. That erroneous belief is nurtured within the IT community; it’s the tangible proof that IT still doesn’t understand the business. Period.

    Joe McKendrick, in his fantastic, “The Elusive Mystique of the Digital Enterprise,” and, “Cloud Computing’s Second Act is All Business,” offers insights likely to help business unit leaders remind their CIOs the business reality, “What matters is revenue.” IT innovation for the sake of innovation doesn’t make sense. And Adam Jacob, co-founder and CTO of IT automation company Chef, in a fantastic article, “The Secret of DevOps: It’s Always Been About People, Not Technology,” gives a DevOps vision that’s totally in line with business unit expectations more importantly to more effectively address digital competitive challenges.

    Adam Jacob’s System of Thought: The Foundations of DevOps’ Second Act

    Adam Jacob defines DevOps as:

    Fundamentally being about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.

    He adds:

    Notice that I don’t mention technology, which may be surprising coming from the CTO of a DevOps-focused company.

    He concludes:

    Tools matter. But tools exist in service of the prime directive: building highly functioning, highly effective cross-functional teams, that attack your thorniest business problems as a unit, rather than as lone individuals or silos with competing incentives.

    This perspective of DevOps unveils an authentic business thinking for IT that I turned into a digital business approach:

    adam-jacob-thought-v2

    It’s represented through the above virtuous circle of principles structured around customer:

    Customer is the source of digital wealth: This expresses the proven belief that being customer-focused increases service quality, keeps customers loyal and, in turn, increases his value of the money they spend to buy services. It prevents customer churn caused by changing consumption habits, whereby digital services are increasingly preferred to traditional services.

    People make, create and innovate: This principle translates the proven idea that giving staff skills, resources, authority, opportunity, motivation, and holding them responsible and accountable for outcomes of their actions, will contribute to their qualification and satisfaction and ultimately make them committed to the organization’s wealth. It creates work environments and work styles conducive to innovation.

    Behaviors and beliefs strengthen involvement and commitment: This principle highlights the demonstrated notion that sharing common beliefs, principles and values creates team spirit, which increases cross-functional collaboration and, in turn, accelerates problem-solving and decision-making. It contributes to the business agility.

    Product is the digital wealth driver:  It’s the now-acknowledged idea that to succeed in the rising digital economy, businesses must align their application delivery approach to the new product development (NPD) principles. Applications take value to customers. It helps to keep up with the fast-paced digital business environment.

    Velocity makes the business responsive to market opportunities: It’s the widely adopted notion that time-to-value is the essential revenue driver that will make businesses digitally wealthy. That principle is enabled by the continuous delivery infrastructure which automates—therefore accelerates—the application delivery processes chain.

    This unprecedented vision, dominant on the business side, contrasts with the technocentric approach promoted by the vast majority of IT vendors to increase their sales.

    Being honest to customers is telling them this: Implementing continuous delivery infrastructure is not implementing DevOps. It will never, on its own, make the business digitally competitive.

    I have no doubt that you’re convinced Adam Jacob, Joe McKendrick and even Ernest Mueller, author of “DevOps: It’s Not Chef and Puppet” are definitely right. The question you might be asking now, which may be provocative is, “Okay, that’s good! How do you implement all that?”

    Implementing DevOps’ Second Act Foundations into a Digital Business Capability

    The first step toward implementing DevOps is to admit that a new IT paradigm is needed, Adam articulates it that way:

    Leaders need to realize that implementing DevOps means changing the technology system as well as the cultural system. They must acknowledge that both are intertwined and, to be successful, both systems must evolve to drive velocity.

    It’s not different from the two-dimension IT advocated in my recent book, “Rethink Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps” and  in my online contents, “Become Digitally Savvy in Just Hours. Boost Your Digital Revenue Now“:

    two-dimension-it

    DevOps implementation is based on four principles that determines successful business transformation:

    Concerns have shifted from technology efficiency to business agility: Forget the outdated idea that IT tools on their own can help your business units succeed. What will make them digitally successful is the combination of technology efficiency and organizational flexibility and agility.

    See IT as a two-dimension asset: To win legitimacy among business units, offer a two-dimension vision of IT including the value stream and the continuous delivery infrastructure. Value stream is where value is created and the continuous delivery infrastructure is what enables business agility.

    The value stream is where the innovation and agility cultures are built: Transform your business organizational structure into an agile value stream through deploying agile practices and methodologies such as Scrum, Kanban and Exteme programming.

    The CD infrastructure is where fast time-to-value is enabled: Automate your applications delivery processes into an accelerated applications delivery chain using automation and continuous delivery tools such as Chef Automation, AWS CodePipeline and Apprenda.

    Summing It Up

    Experienced DevOps Strategists know that DevOps is the means to an end, and not the end itself. DevOps is an enabler to one or a combination of these business competitive advantages: short time-to-value, market responsiveness, innovation culture and many more.

    All the noise surrounding the so-called DevOps tools has to do with technology business—making money through selling IT tools—and absolutely not DevOps.

    DevOps isn’t a tool, it’s an IT approach stressing business competitiveness: shorter time-to-value, market responsiveness and innovation.

    — Philippe Abdoulaye

  • An IT Practitioner’s Guide To DevOps

    An IT Practitioner’s Guide To DevOps

    Two technology innovations of the past decade have fundamentally changed how IT works and given rise to the “DevOps” phenomenon. Before we dive into what DevOps is and how IT organizations should adopt this culture, let’s review what gave rise to it in the first place.

    Pull from Agile Development

    The last decade has seen many organizations abandon the traditional “waterfall” software development process in favor of “agile” development. Agile is all about small, specific user-centric stories, described by a product owner and delivered in short sprints of two to four weeks by small, focused development teams.

    Agile development led to the emergence of more frequent code drops from software engineers, which needed to be deployed more quickly. No longer was it okay to take days or weeks to deploy a new software version; developers working in two-week sprint cycles want deployment to work within minutes with a high degree of predictability.

    Enabled by the Cloud

    Before the cloud came along, access to infrastructure required human interaction and manual operations. Processes typically could not be automated effectively. This meant that operations were slow and error-prone and created a huge point of friction in the software development life cycle.

    Around the same time that developers were adopting agile development, the cloud became real, and infrastructure could be orchestrated effectively using APIs to provision everything from machines and networks to storage, routing policies and firewalls.

    DevOps: Closed Loop Automation Between Development and IT

    Agile development and cloud computing created the perfect storm in which DevOps was born: this new way of doing IT is all about ensuring closed loops, with 100 percent automation.

    picture2

    Figure 1: DevOps is about ensuring a closed-loop, fully automated workflow between software development and deployment.

    In the simplest terms, this meant that each of the steps outlined in Figure 1 need to be fully automated, and integrated with preceding and following steps. Doing this ensures software can be developed faster, deployed quickly, and iterated upon more rapidly.

    Benefits

    Done right, DevOps leads to a virtuous cycle of greater productivity across development and IT, greater agility in bringing new experiences to market and greater impact on the business.

    Adopting DevOps: You Can Phase It In

    Organizations looking to adopt DevOps should do so in phases and define metrics for each phase. Here’s a typical phased approach that you can use as a baseline and customize to your organization’s unique needs.

    Phase 1: Adopt Agile Development and Cloud Computing

    Agile development and cloud computing are profound technology shifts and create the underlying culture in which DevOps can thrive. So, the first step is to ensure organizational buy-in for both of these trends:

    1. Agile development can be adopted in stages. The most important is to agree that software will be built and shipped in short, two-to-four-week sprint cycles, and with a focus on user stories.
    2. Cloud computing can be adopted no matter what your IT infrastructure looks like today. Use hybrid cloud platforms such as OpenStack to provide programmatic access to a VMware or Linux environment, or use a public cloud platform such as Amazon Web Services.

    Phase 2: Commit to a CI/CD Workflow

    Continuous integration (CI) systems such as Jenkins or TeamCity provide a way to pipeline and integrate the various steps in a DevOps workflow. The choice of system doesn’t matter as much as ensuring that all steps of the workflow will be integrated (eventually) into this workflow.

    Phase 3: Repeatable, Automated Software Deployment

    Many organizations tend to have some manual steps in the packaging and deployment of their software, especially for getting it into production. This often reflects underlying assumptions about manual oversight and intervention, and it breaks the closed-loop philosophy of DevOps.

    To succeed with DevOps, you need to fully automate the software packaging and deployment process. In addition, ensure that production builds are deployed in the exact same manner as developer builds, using identical environments.

    Cloud technologies such as orchestration (OpenStack HEAT or AWS CloudFormations) and configuration management tools such as Ansible, Puppet or Chef can be used to implement this phase.

    Phase 4: Automate Software Testing (Continuous Delivery)

    Once software deployment has been automated, the next phase is to automate the validation process for new software releases. If you’re like most organizations, testing involves several rounds of back and forth with QA teams and product managers, and it often takes weeks to resolve the last few bugs in each release. To reach the next level of DevOps automation, this process has to be completely lights-out and automated.

    This requires a fully automated software test suite, across the back-end and front-end, so that product managers have confidence in the quality of the software being released. Once implemented, you finally have a closed loop between the critical elements of the DevOps life cycle. While release to production may still require someone to approve it or “push a button,” this is a very respectable state in the DevOps journey.

    Phase 5: Continuous Deployment

    To get to the most advanced DevOps phase, you need to automate the “go live” process for software releases. This in turn will allow you to take even smaller, more frequent code drops and push them into production.

    The most advanced software teams in the world now operate this way, and the organizational implications can be transformative: Developers come into work feeling that they can implement a feature and have it go live immediately, and product managers can make commitments to the business with the confidence they can deliver, because they have this incredibly efficient software delivery machine backing them. Most importantly for you, IT is no longer seen as a cost center; it’s seen as the fundamental enabler for business productivity and time-to-value.

    Closing Thoughts

    Getting to Phase 5 represents the state-of-the-art in the industry today. However, another significant breakthrough promises to raise the bar even higher.

    In each of the prior phases, the DevOps workflow is integrating software development with IT operations; but there is nothing influencing software architecture to take operations into account.

    In other words, we’re still bolting IT operations automation onto software development.

    This is about to change. We’re on the cusp of a new era in software: instead of bolting operations onto the software development process as an afterthought, a new framework promises to bring development and operations together by design. With declarative, infrastructure-agnostic constructs to describe how applications are composed, interact and managed, Kubernetes promises to increase the operability of modern software systems by an order of magnitude.

    Everyone interested in the DevOps journey should be learning about Kubernetes and evaluating how it will improve your software development and operations workflows.

    About the Author / Sirish Raghuram

    sirishr_platform9Sirish Raghuram is co-founder & CEO of Platform9. As CEO, Sirish quarterbacks the team at Platform9 in realizing the company’s vision, which, on a given day, can range from strategy and road map to shipping code and running tests. Before co-founding Platform9, Sirish was an early engineer at VMware, where he held technical and management leadership roles and helped ship multiple vSphere products. Sirish’s work was reflected in several patents, VMworld talks and internal product innovations within VMware Engineering. Sirish has a B.E. in Computer Science from the University of Pune, India. Connect with him on LinkedIn.

  • Last-Mile DevOps: How to Keep Employees Happy

    Last-Mile DevOps: How to Keep Employees Happy

    Chances are that your company is embracing DevOps to make sure you can get fresh, new digital capabilities to your customers ASAP. That’s because in today’s market, you either have to be first—or quickly close any gaps between you and your more digitally innovative competitors.

    But when it comes to getting new capabilities into the hands of your own employees, things probably move much slower. That’s because your internally facing apps have to clear a hurdle that your customer-facing apps don’t: administration of access privileges that often are poorly defined and inadequately automated.

    That’s a problem. People can’t be productive if they don’t have access rights for the IT resources they need, when they need them. The growing Millennial workforce is going to be especially unhappy if IT is slow to meet their digital needs. And from a security perspective, slow administration of access privileges is also a problem—because your company must be able to automatically and immediately revoke employee access privileges the moment they’re fired or they quit.

    This automated, accelerated management of internal users’ access rights is the missing “last mile” for DevOps. And it’s something you have to address if you’re going to fulfill the needs of the business with the same excellence as you fulfill the expectations of your customers.

    What Makes the Last Mile So Tough?

    If you bank with Chase or ride with Uber, your access to your personal data is gated by your personal login. But, as a customer, you essentially use the same app as everyone else.

    Application privileges within your own company are entirely different for two reasons:

    • Privileges for your internal workforce are much more complex than for customers. Salespeople have sales apps. Your finance department uses finance systems. Your service reps may be allowed to see RMA numbers, but not SSNs. So you must quickly give each person access to only the resources appropriate to their specific role and responsibilities—or risk consequences that include lost productivity, security breaches, compliance failures and excess software licensing costs.
    • Management of internal privileges is an ongoing activity. Productivity, security and compliance demand that you provision each user account for each application with the right privileges at the right time. Privileges must be immediately and appropriately modified every time an employee is promoted or transferred. Privileges must be terminated immediately when someone leaves your company. Privileges may also have to be temporarily modified in real time due to session context—such as use of non-secure public WiFi or an access attempt from a questionable location or at a questionable time.

    Simply put, for internally facing apps, getting code onto a production server isn’t enough. You also need to automate and accelerate management of the “last mile” between servers and employees.

    What Are ‘Last-Mile’ DevOps Requirements?

    DevOps toolchains automate and monitor the software life cycle from design and development through testing and deployment on a production server. What’s missing is automated provisioning and governance of the “last mile” between the server and the individual worker.

    These tasks include:

    • Capture of current user role/responsibility profiles from HR
    • Provisioning of application-specific accounts with profile-appropriate privileges and controls
    • Self-service inputs from authorized LOB managers
    • Detection of session context (network connection, time of day, location, etc.)
    • Real-time modification of privileges based on that session context
    • Automated revocation of access privileges upon termination, transfer, etc.
    • Employee self-service for permitted optional applications and services
    • Monitoring and reporting on employee account activities and events

    Your team probably performs many of these “last mile” tasks manually. Some may also be automated using homegrown scripts. Excessive dependency on scripts is a bad practice, though. Scripts usually are poorly understood by anyone but the original writer—which makes them difficult to maintain and update over time. They also don’t typically integrate well with DevOps, HR systems or other key pieces of the app delivery puzzle. This lack of integration slows your processes down and opens the door for human error.

    Automation of last-mile DevOps makes much more sense. Automation speeds processes, reduces cost and optimizes accuracy. Integrated automation also gives you a dependable, centralized point-of-control for defining and editing policies—as well as for capturing the event logs necessary for compliance and security reporting. The right automation solution will also integrate with the rest of your operations environment (including directories, VDI, and mobile management tools) to ensure secure, reliable application access.

    Why is ‘Last-Mile’ DevOps Important?

    Most business leaders already understand why rapid rollout of customer-facing applications is so important. Unfortunately, many fail to recognize the importance of being just as fast and accurate when it comes to supporting their own workforce.

    The truth, however, is that automation of last-mile DevOps benefits your business in several important ways:

    • Improved employee productivity and engagement. Your workforce will be much more productive and more engaged when everyone has immediate access to the digital tools they need. That improved employee performance will benefit your customers as well.
    • Higher IT efficiency. The sooner you automate the many everyday service provisioning tasks that your skilled IT staff now performs manually, the sooner they can to shift their precious time and energy from routine work to higher-value projects.
    • Enhanced security and compliance. Well-defined access policies, diligent enforcement of those policies with rules-based automation and centralized logging of access provisioning activities all reduce your IT-related risks—as does immediate, automatic and complete revocation of all access privileges the moment any employee or contractor is terminated.
    • Reduced “Shadow IT.” When IT is more responsive to people’s needs, they are far less inclined to turn to alternative digital resources that aren’t properly monitored, governed or secured.
    • Greater business agility. M&A, reorgs and other organizational moves are chronically bottlenecked by manual execution of mass changes to the workforce’s digital access privileges. Rules-based automation of last-mile DevOps eliminates this agility-killing process friction.

    The bottom line: To achieve true digital agility, your company must automate the “last-mile” tasks that give your people access to the IT resources they need—when they need them.

    About the Author / Stacy Leidwinger

    stacy-leidwingerStacy is the VP of Products at RES where she is responsible for defining overall product direction, roadmap and positioning, to drive product excellence, company growth and customer success in the areas of end user computing and security. Her background is in both product marketing and product management helping to positioning B2B software companies for growth and market leadership. Prior to RES, Stacy led the product management team at Directworks, a cloud-based sourcing and supplier management solution. Before Directworks, she managed the roadmap, product positioning, and go-to-market strategy for Vivisimo, an enterprise search solution, which was acquired by IBM. While at IBM, Stacy was responsible for the integration of Vivisimo’s product line into IBM’s big data portfolio. Connect with her on LinkedIn / Twitter.