Category: Features

  • Road to Modern Ops

    Road to Modern Ops

    This is the first lesson in HashiCorp’s Road to Modern Ops, an interactive curriculum dedicated to guiding organizations from manual processes to modern, automated operations. This essay sets the foundation for the curriculum by outlining manual operations tasks and the path towards automation. To put this knowledge to work, explore the interactive tutorial to learn how to manually manage an operations workflow.

    A letter to operators, sysadmins, and devops-ers: don’t lose sight of operation’s end goal. The goal of operations is to turn application code in development into a running application on a production server through a safe, error-free process. This is done in three general steps — server provisioning, server configuration, and application maintenance. Over the past few months and even weeks, there have been a mass of technology announcements relating to these three steps and the operations space overall — new container technologies, minimal VMs, configuration management tools, monitoring tools, automated provisioning tools, service discovery systems and more. As a result, the operations industry has gotten caught up in these details but lost sight of operation’s end goal.

    The technologies in the operations workflow are prone to change, as shown by the past few months. However, the operations workflow itself – moving an application from development to production – is unlikely to change in the near term. The main advancement in the general operations workflow is the rise of automation to replace manual tasks. This is often referred to as “DevOps” (one of DevOps’s many interpretations). Modern workflows embrace automation to reduce human error, scale deployments with the same number of operators, and increase transparency across the process.

    While most organizations have the same end goal of an automated, error-free, and quick operations workflow, it’s confusing how all the different operations tools fit together to accomplish this goal. How do Jenkins, Chef, Vagrant, Docker, Terraform, Datadog, etc relate to each other? How can they be used to build an automated deployment process? The transition from manual configuration, provisioning, and service discovery to fully automated, modern ops is an unclear path.

    The road to modern ops — automation and the modern datacenter

    “Road to Modern Ops” is an interactive curriculum by HashiCorp to guide organizations to modern, automated operations through a gradual and detailed educational process. Each lesson takes a manual process and demonstrates how to automate it through an interactive tutorial. By the end of the curriculum, participants will understand the components of operations, how to automate those components, and finally how to combine the components into a fully automated application delivery workflow.

    The first tutorial lays the foundation for the curriculum by walking through manual configuration, provisioning, and maintenance. Subsequent lessons automate one component at a time, and then unite them to form a cohesive, automated operations workflow. The goal of the curriculum is to not only provide hands-on experience with automation, but to understand how the tools fit into the larger operations ecosystem. Start on the road towards modern ops.

     

    atlas-hashicorp-com-road-to-modern-ops

     

    About The Author  ⁄ Kevin Fishner

    unnamedKevin Fishner is the Director of Customer Success at HashiCorp. He has extensive experience working with customers across HashiCorp open source and commercial products. Philosopher by education (Duke), engineer by trade. Connect with Kevin on twitter.

  • Mobile developer trends for CI and the cloud

    Mobile developer trends for CI and the cloud

    Mobile developers understand the rising importance of continuous integration (CI). The promise of CI is to speed up the overall velocity of the app team by building and testing every single code change. This environment of rapid change means that code integration issues are caught early, and testers and beta users can provide feedback on these changes as quickly as possible. As CI has become commonplace for app development teams, and many are moving their CI infrastructure to the cloud, the importance of build and regression test automation has grown.

    To that end, we thought it would be important to generate a research report by examining survey data from more than 500 mobile app developers and benchmarked usage data from more than 250,000 automated builds, tests and releases on the Ship.io platform. This Mobile Metrics Benchmark Report shares insights and trends around the Continuous Integration (CI) landscape in regards to mobile app development. Key areas of focus for the report include CI adoption across major mobile operating systems (iOS, Android), frequency of testing, releasing and checking code, app build times and frequency, and common build failure reasons across geographies around the world.

    v3-Ship_io-Infographic-FINAL-8_3_15-01-580x1024

     

    OVERALL CI ADOPTION
    Of app teams surveyed, the majority are leveraging CI. Those not leveraging CI are often building only on-demand when they want to test a build, or are building with a simple regularly scheduled nightly or weekly build scheduler. Of teams that are leveraging CI processes, the majority of them are running some form of test automation on each build. Here’s a breakout:

    • Less than 5 per week: 15%
    • Between 5 and 25 per week: 33%
    • Between 25-50 per week: 33%
    •  More than 50 per week: 19%
    • No, not doing CI right now: 37%
    • Yes, doing CI builds and tests: 35%
    • Yes, doing CI builds: 28%

    THE CLOUD CI ADOPTION LANDSCAPE: Cloud CI Adoption: iOS vs Android
    Many app teams have adopted Continuous Integration as part of their engineering processes. Some teams have set up CI as an on-premise service, but many are moving this to the cloud for reasons such as cost savings, focus, and reliability of the CI system. An oft-cited reason for moving to cloud CI systems managed by others is the complexity and cost of keeping up with all the changes in the iOS and Android build and test ecosystem.

    Of all developers surveyed with an interest in Cloud CI, but not necessarily using CI systems today, the majority (50%) are only focused on iOS—ignoring Android altogether. Other developers are focused on both platforms, with a small minority focusing only on Android.

    PUBLIC vs. PRIVATE APPS
    Developers with an interest in CI are overwhelmingly building apps for Google Play and the App Store. Only a small fraction of these developers are building apps for internal use, or with a limited number of customers. Many of these internal-facing app teams have smaller app teams and longer release cycles, presumably diminishing their need and interest in continuous integration systems.

    WHY BUILDS BREAK AND BUILD SPEED METRICS
    As many app teams have moved to a continuous integration (CI) model for development, they produce many more builds. This increase in build frequency means that the time spent building is far more significant, and broken builds can randomize and delay product progress. The data shows that the majority of build breaks are avoidable, and the time spent building apps is low, but iOS builds are about twice as fast on average versus Android.

    Analyzing the source of build breaks across both iOS and Android reveals that there is a very long tail of build breaks as many engineers would suspect. Builds often break due to of various developer code syntax issues, but several build breaks account for the vast majority (74%) of all breaks in cloud CI builds:

    • Missing File or Directory: Developers often forget to check dependencies and new files into the code repository.
    • Lint Errors: When ‘lint’ is enabled on a build, it often catches common programming errors.
    • Unit Tests: Many apps have regression test automation at the unit level. These tests fail during the build process, catching either changes in the app, or regressions.
    • Linking: Builds often fail at link time because a referenced 3rd party library wasn’t added to the dependencies list, or project dependencies were not updated.
    • Code Signing: The process of signing apps is still error prone. From missing signature files, or differences in debug versus release build configurations, code signing causes many CI headaches.

    The good news is that most all of these build breaks could be caught by developers having a separate ‘clean’ enlistment and building and running lint locally. Even more breaks would likely be prevented if developers simply executed unit tests before submitting new code. Barring that, cloud CI systems make it easy to catch all these issues, and mark the build as failed until developers resolve the break.

    BUILD TIMES: iOS vs. ANDROID
    When app builds break the team is often blocked and waiting for a new build. Build times are now a critical path for app teams. Analysis of iOS versus Android build times reveals that although iOS app build times are about twice as fast on average, the build times are still reasonably short at 2 minutes and 4 minutes on average, respectively. A deeper look into the build time data shows that very few app build times, regardless of platform, exceed 30 minutes. The majority of app build times are less than one minute. An interesting aspect of build times is the fact that more Android than iOS app builds complete in less than 2 minutes. But of all large/complex app builds (longer than 2 minutes), iOS app build times are generally faster by a factor of 2.

    COMMIT FREQUENCY OF IOS vs. ANDROID CLOUD CI TEAMS
    Of the top 40 apps with the most frequent commits in the study data, 67% of them were iOS Apps. It is worth noting that the study data had builds from app teams that built both Android and iOS versions of their apps. iOS developers seem to be committing code more frequently and adopting the CI model of small, continuous commits.

    COMMIT FREQUENCIES: IOS vs. ANDROID
    iOS developers make far more revisions than Android developers. Across the spectrum of commit frequency, iOS developers, on average, are making twice as many commits as Android developers. The majority of apps have one commit per week, or fewer. Of those that are very active, defined as committing code more than 3 times per week, about two thirds of those developers are working on iOS. The aberration seen where Android developers are building 6 times a week, is due to a single app vendor with many apps, all sharing a common code base with many Android apps (with commit frequencies at 6 times per week). In general, iOS developers are about twice as likely to make more than 3 commits per week versus their Android counterparts. In total, iOS developers, on average, are making twice as many commits as Android developers.

    TOP PRIORITIES INCLUDE FASTER RELEASES
    Of all the things app teams were looking to prioritize in the coming year, faster release and update frequencies (41%) was a close second only to improving overall app performance at 48%. Teams are quickly migrating to Cloud CI systems as a way to accelerate their overall velocity. Cloud CI enables teams to focus their time and money on other priorities such as performance and security.

    WHY NOT CI?
    The reasons why teams haven’t adopted CI vary widely. 49% are interested and plan to move to CI eventually but haven’t because of prioritization. Some teams believe they are too small to benefit from the value of CI as their team only has one or two people working on the builds, or they have so few code revisions that they prefer to deal with builds manually. A minority of app teams are concerned with the cost in money or time to move to a CI system.

    Why Deverlopers are Not Adopting CI

    CONCLUSION
    These Ship.io study results show that the world of CI for app teams is changing quickly and varies between iOS and Android app teams. Knowing the macro-level trends and learning from them, can greatly impact your app teams efficiency. As app teams accelerate due to CI adoption and agile practices, teams are often spending an inordinate amount of time focusing on their local and custom build and test infrastructure. Those app teams that have moved to the cloud are saving money and time and focusing more on their app design and implementation.

    • CI Adoption: Cloud CI adoption is on the rise, especially in the iOS community. iOS developers are more aggressively adopting cloud CI than Android developers. The number of teams adopting Cloud CI is doubling every 6 months.
    • Commit Frequency: There is a wide range of commit frequencies across iOS and Android. iOS app developers generally have twice as many commits as Android developers. The commit frequency and the number of builds range from a high of around 16 per day, to a low of once every other week.
    • Source Control Popularity: Two cloud source control repositories represent almost all cloud CI systems: GitHub and Bitbucket. The momentum is strong with Bitbucket which saw its share of usage double in just the past 4 months. Android users seem are more aggressively moving to Bitbucket, but iOS developers aren’t far behind.
    • Build Breaks: Several common issues account for the majority of build breaks, but there is a very long tail of build break reasons. The good news is that many of these are avoidable.
    • Build Time: Build times on iOS and Android are similar and range from mere seconds to a high of 40+ minutes for apps with larger code bases and dependencies.

    Download the full report here

    shipIO-report

     

     

     

     

    About the Author/Prathap Dendi

    leadership-prathap-dendiPrathap is GM for Ship.io, and VP Business Development for Electric Cloud. He drives strategic partnerships that help us deliver broader solutions to our customers. Electric Cloud has forged strategic partnerships with companies providing industry-leading tools and services in order to deliver software production automation to our customers.

  • A Slice of Groovy’s Hip Use of JFrog Artifactory & Bintray, and of Gradle and TeamCity

    A Slice of Groovy’s Hip Use of JFrog Artifactory & Bintray, and of Gradle and TeamCity

    Grrroooooovy, Baby!

    Groovy supporters describe the Groovy programming language as dynamic and statically typed, supporting functional programming and OOP as a superset that includes the Java programming language. “It’s a kind of Java on steroids if you will!” says Guillaume Laforge, an Apache Groovy project PPMC member. A few examples of common applications of Groovy will help to illustrate its position in the programming landscape.

    Developers use Groovy in the build and test phases of a variety of projects even though they did not code their applications in Groovy. Coders find Groovy an inviting language for writing and maintaining tests due to its reader-friendly concision. “Developers use Groovy with the Spock Framework for unit testing and behavior-driven development and with Geb for Web integration testing,” says Laforge.

    Programmers use Groovy scripts for application extensibility for integration, configuration, customizations, and plug-ins. “The Jenkins Build Flow plug-in is a prime example as it enables users to orchestrate jobs by using the Groovy language to extract those jobs’ flow logic,” says Laforge. Other uses for Groovy include domain-specific languages, administration, automation, and Web, desktop, and mobile application development.

    devopsy.kinsta.cloud explores elements of Groovy’s trip from manual to automated development.

    Manual Processes, Not So Groovy

    When the developers of the Groovy language released software from individual developer machines and using other manual processes, this created several issues. If a developer neglected to give birth to a dedicated release branch, this could equate to non-committed files and local changes transferring directly into the release prior to joining the mainline source tree, skirting prudent source control requirements.

    “Or we could simply forget to set tags for releases or we could commit errant version number data,” says Laforge; “although the release’s version is x.y.z., the version in the manifest would be x.y.w.”

    In some cases with individual developer machines, new developers would experience discrepancies. For example, a new developer performing a project build could see dependency-related challenges such as when one project depends on another that has corrupted “pom” (Project Object Model) files. “Local repositories would fill up with odd dependencies,” says Laforge. There were other issues, as well.

    Groovy Fully Automates Its Release Process

    One of the progressions that Groovy made toward automated bliss was in the realm of version control. Groovy eventually moved from CVS to Subversion to Git and from Codehause to Github as its repository. “More recently, we moved the sources to Apache’s Git, as Groovy entered the Apache Software Foundation incubation process,” says Laforge.

    Today, Groovy developers send snapshots to the JFrog open source Maven repository, Artifactory, to test their bug fixes and features. According to Laforge, Groovy applies the JetBrains TeamCity CI server to build artifacts and distributions; the Artifactory plug-in for TeamCity enables Groovy to stage releases using Artifactory. Artifactory and Bintray integration enables Groovy to push everything to Bintray. Dependency management occurs on Bintray’s JCenter Maven repository. Synchronization with Maven Central supports developers who are retrieving dependencies.

    The Gradle build automation tool supports a mature build setup for Groovy, allowing the language developer to bootstrap its own compiler, enabling it to build Groovy code. “This is part of our deliverable, i.e., Groovy basically compiling itself,” says Laforge; “this would be much more difficult using other build solutions.”

    Drilling down, there are more benefits to having Gradle and TeamCity working in tandem. For one, it affords Groovy the opportunity to test different flavors and functionalities of Groovy on different platforms and environments. “We can do this using different JDK versions from 6 up to the as yet unreleased ver. 9, testing against our own snapshots and using different flags for testing and building Groovy with or without the invoke dynamic support from JDK 7 onward, with different branches,” says Laforge.

    Reinstituting Manual Processes for Apache

    On entering the Apache Software Foundation, Groovy had to re-introduce manual steps in order meet Apache guidelines that state that Apache committers must build projects themselves and that they need to sign their deliverables with their own keys. “We are still using Gradle, JetBrains Team City, and JFrog Artifactory and Bintray, but not in as much an automated fashion as before,” says Laforge.

  • DevOps Chat: Rosalind Radcliffe, Mobile to Mainframe DevOps for Dummies

    DevOps Chat: Rosalind Radcliffe, Mobile to Mainframe DevOps for Dummies

    mtmdummies_large

    I recently had a chance to sit down with IBM Distinguished Engineer Rosalind Radcliffe about her new book, Mobile to Mainframe DevOps for Dummies. The book is actually quite a bit deeper than your usual “for Dummies” book and an excellent read. Of course you would expect as much coming from Rosalind who has quite a list of well deserved accomplishments and accolades on her CV.

    Saleem Padani of IBM has a good post up on LinkedIn announcing the book as well that you may want to check out.

    FYI, we will be doing more DevOps Chats in the future. If you would like to be a guest on a future episode please contact editor@devops.com

    Above is an embedded audio player to listen to the interview of Rosalind. Below that is the transcript if you would like to follow along or just skip the audio and read the interview. You can download the free e-book copy now by visiting https://ibm.biz/m2mdevops

     

    Audio Transcript

    Alan: Hi, everyone, this is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud, and we’re kicking off a new feature here at devopsy.kinsta.cloud—DevOps Chats. Each episode will feature me speaking with a thought leader around a particular topic of devops.

    Kicking off our series today with a very special guest, Rosalind Radcliffe of IBM, and we’re gonna be talking to Rosalind about a new book which she has just offered called Mobile to Mainframe: DevOps for Dummies. Rosalind, welcome to devopsy.kinsta.cloud.

    Rosalind: Thank you.

    Alan: Okay, let me briefly give our listeners a little background on Rosalind, and Rosalind, I don’t mean to embarrass you, but you have quite a résumé. Rosalind is a Distinguished Engineer in IBM. She’s Chief Architect for CLM and DevOps, and she is responsible now for driving devops for multi-platform architecture. This includes System z and Power Systems. In addition, she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions, and this includes both UrbanCode Deploy and Rational Team Concert’s support for standard mainframe development activities.

    Beyond that, Rosalind is a member of the IBM Academy of Technology and a master inventor. Prior to her current development related responsibilities, she has been responsible for IBM’s SOA Management Strategy and Services, responsible for deploying Systems Management solutions, and she started with ISPF development.

    Rosalind, I hope I didn’t embarrass you too much, but once again, welcome to devopsy.kinsta.cloud, and congratulations on this great new addition to the DevOps for Dummies series, Mobile to Mainframe DevOps for Dummies.

    Let’s start today’s chat, if you can share with our audience a bit more about you and where you are in your career.

    Rosalind: Thank you, and I’m looking forward to this chat. So, a little history on why I wanted to write the DevOps for Dummies book. I started in IBM 28 years ago in ISPF development, as you mentioned, and I’ve been in different roles and different responsibilities along the way, including spending a good amount of time in the Systems Management organization, responsible for actually doing operations like tasks and deploying our Systems Management solutions for clients.

    I’ve also spent a number of years in the application development space, providing and building application development tools. And so, as this developed over the years, working in operations, I used to blame development, and then when I moved to development, it was, “Oh, I guess I can’t blame operations.” So it’s deemed appropriate that I would move into this devops space of trying to bring these teams together.

    In looking out at the industry today, I see that there are lots of questions, especially in the mainframe space, about, “How does this devops really apply to that environment, and with all the drive for mobile and mainframe together, how do we really make this play as an environment?” And so, that’s how I got here and why I wanted to write this wonderful book.

    Alan: So, let’s dig in quickly to the book. You know, I think everyone in our audience is familiar with the “For Dummies”, if you will, franchise, and some of them can be rather fluffy, some are better than others, obviously, depending on authors and so forth. My initial reaction when I read it, Mobile to Mainframe DevOps for Dummies was, “Wow, that’s a pretty heavy topic for a For Dummies book.” Why write this book in the first place and why now?

    Rosalind: Well, I think now is a perfect time, with the industry evolving, with the mobile frontier and everybody focusing on mobile, and with mainframes truly being our systems of record. So, everybody needs to connect mobile to mainframe, and if we look at the development environment, most mainframe development shops look remarkably like they did when I started 28 years ago, and that’s not necessarily a good thing.

    So what I wanted to do was help explain to executives, senior leaders, and anyone in the industry, how mobile and mainframe play together and, in using the devops transformation helping them work together, they can get more value out of the systems that they currently have.

    Alan: Absolutely. And just so we can mention, of course, Rosalind, the book is available for download, we’ll have links on it up on devopsy.kinsta.cloud. But, as I mentioned, it’s not a fluffy book—there’s a lot of great content here. I can tell how much time and effort you put into this thing.

    But, give our audience a sense—how much, how big an effort was it for you?

    Rosalind: It was a significant amount of time in writing. I spent a lot of time on plane flights back and forth to Europe, and that gives you a lot of time when you can’t do anything else, and so I spent a significant amount of that time writing. It’s a relatively short book, it’s only 70-something pages, so it’s not as long as a very long book, but it did give me the opportunity to hopefully give some background, explain more about the current environment, and give people an insight as to what I’ve been seeing with clients and help them move forward.

    After you write it, then you have to edit it, and I have to thank the many people that helped me work on this and help provide contributions and pieces of the document, because they helped me put this together, and helped me do a lot of editing as well to make sure that it was complete in the environment.

    Alan: Sure. I mean, I’ve been lucky enough to have a chance to see a pre-publication version of it, and I do think—you’re right, it is only 70-some odd pages, but it’s pretty in depth. But it really benefits from the sort of, the For Dummies kind of franchise—you know, the icons they use to help you focus in on what’s really important and giving you Cliffs’ Notes version if you wanted to not read every word. You used the format very well, and I think people will get a lot out of the book.

    Let’s dive in a little bit, though, into some of the key points that you’ve brought up in the book. You know, just picking some random ones that I thought were important—in chapter 3, for instance, you speak about why we need to understand why devops is so critical for mainframe environments. And we need to start with the dev side.

    But devops is about breaking down silos, it is about cross functions—and nowhere, in my mind anyway, nowhere are these silos more separated than between the mainframe teams, like you said, haven’t changed sometimes in 28 years when you started, and the distributor mobile development teams, who are today all about cloud and virtualization and instant up and instant down.

    Can you elaborate a little bit more on this point for our audience?

    Rosalind: Yeah, I’ll be happy to. This is one of the key points as to why devops matters more than ever now in the mainframe space—this transition to mobile, this transition to systems of engagement and their dynamic changes, their need for speed, and the need to access these back end systems of record. So now is the time for us to evolve the environment, the mainframe development environment, to modern technologies and modern tools to allow these teams to actually work together.

    There is absolutely no reason that mainframe environments need to do development the same old way. They don’t need to be done using waterfall development practices. There’s no reason not to apply the same agile and lean IT practices across the development organization from mobile to mainframe, and using the same tools and the same capabilities so these teams can work together, they can share information, they know what each other’s doing, and you can break down those silos.

    One other reason those silos are there is, you know, if your mainframe development team is using ISPF, I’m not sure those mobile guys using X code even want to look at a green screen. So this has to change. The perfect time—bring these teams together, use modern development practices, use modern tools, and this allows the silos to be broken down, allows the teams to work more efficiently together, and helps deal with this variable speed IT issue that we have. Mobile needs to move fast. Those systems of engagement need to be moving.

    But the back end systems of record need to be able to define standard APIs. They need to provide those services that the front end needs, and they need to do it fast enough—so they need to do it at the speed of business, and devops helps them do that.

    Alan: Excellent. And so, Rosalind, you actually touched on something here, and it’s this variable speed IT—variable speed devops, I’ve heard some analysts call it a bimodal  IT—and it, I mean, you nailed it right on the head. These mobile development teams that are running at the speed of today’s business, tearing it up, putting it up, tearing it down, putting it back up—changing, changing, changing thousands of hundreds of times a day, even, in some cases.

    We can’t expect the mainframe systems of record to perhaps move at that pace, but there’s no reason they can’t move faster, especially using modern tools, modern development environments, though I still find something comforting about a green screen. [Laughter]

    But, that being said, you know, this was the subject of a whole series of webinars we did here on devopsy.kinsta.cloud on variable speed IT and variable speed DevOps. Can you help our audience understand why it’s so critical for mainframe environments to embrace devops and why now, more than ever, now is the time?

    Rosalind: Yes, so with this variable speed IT, and as we talk about it, it’s not that the back end is slower because mainframe development is slower, it’s that, in variable speed IT, you need to move at the speed of business, and if you define services as your back end systems of record, those don’t need to move as fast.

    What we need is to define those as services so the front end system can use them, so these systems of engagement can call back into the function. So the need to define these services based on the existing legacy code means development teams need to be able to respond at the speed of business. They need to be able to move faster. And the old ways of doing things—you know, making a change and testing it for three months—just isn’t gonna work. We need to apply the principles of automation, automated testing, virtual services, and interface testing, and bring all of those concepts to allow you to build those services based on the existing business function into the environment so that they can then be called by the systems of engagement.

    Companies have significant assets sitting on the mainframe systems. Mainframes aren’t going away. They’re gonna be here forever. They provide the qualities of service needed for large scale transaction performance systems. And so, with mobile, large scale transaction performance systems—that’s perfect. Mobile backed with mainframe is a perfect environment. And companies with the assets that they’ve built up, if they can service-ify them fast enough, they can provide disruptive technology today.

    And that’s what the companies need to do. They need to take advantage of the assets they have, providing services using the new development practices, and then it all fits together and they get the business value at the speed they need to. And you know, I helped build ISPF, so I do like that green screen, too—but it’s not really the right development platform for developers today.

    Alan: Yeah. But what about—look, you know, people make fun of COBOL developers, but there’s still a lot of jobs out there for COBOL developers.

    What about the shortage of experienced mainframe IT skills in the marketplace, Rosalind?

    Rosalind: Yeah, so that’s one of the points I make in the book. Developers can write any language. You know, get a good developer, they can write COBOL—and there’s nothing wrong with COBOL. COBOL serves its purpose. PL/I serves its purpose. And some people will cringe as I say this—Assembler serves its purpose. But you know, I’m not gonna write it using ISPF.

    If I’m a kid coming out of college and you give me a modern IDE that has all of the language syntax in it, it has code rules, it has the ability to build unit tests for me—I can write COBOL. Not a problem. It’s the—give me an ISPF screen, and I don’t even know how to use it, much less how to do COBOL.

    Alan: Understood, understood. Let me—we’re running low on time, so let me turn to some other questions I had prepared, if it’s okay. In the book, you talked about some of the best practices—devops best practices on System z which, for our listeners who may not be IBM aware, System z is the IBM mainframe platform.

    Rosalind: Correct.

    Alan: And there are several good ones that you have highlighted in the book. Are there specific devops practices that you would recommend for System z to get started down the path of continuous delivery, which some people think is the ultimate aim of devops, or the ultimate goal?

    Rosalind: Yeah, so there are a number of different practices, but a few call out based on the way many mainframe organizations are working today, and it has to do with where they are today. How do they improve the process from where they are to get into more continuous delivery practices?

    And before someone says something, I’m gonna say—continuous delivery does not necessarily imply continuously delivering into production. It means continuous delivery into a pre-production, et cetera, environment. You may still need to stage those based on an outage window, especially for systems of record, because you can’t afford to have a transaction change mid-flight.

    So there are some—you know, continuous delivery within reason. But if we think about those things, one of the key practice is modern development tools to break down the silos. And one of the others that is absolutely critical is automated testing. There is no way to get to continuous delivery without automating testing, and since you’re building services out of your back end systems, services are a perfect thing to use automated testing against.

    So, building up automated testing based on the service interface, being able to test the function without having to have users go in and test the business function—just run a bunch of automated tasks and make sure you’re picking the right automated task based on the code that you’re changing, but automated testing is probably the biggest change that is needed for mainframe environments and, in many ways, the most valuable. We look at many shops and they’re spending months running lots and lots and lots of manual tests that they hope will find the problems.

    Alan: Got it, got it. Rosalind, we only have time for maybe another question or two, but I have one very IBM specific one, one a little bit more general.

    So recently, the new z13 launch really put the mainframe front and center as the core element for IT infrastructure.  Is this the rebirth of the mainframe? How do we see this new mainframe fitting into this seemingly ever changing IT landscape? More importantly, what do existing mainframe clients do to prepare for this new age of mobile to mainframe?

    Rosalind: So, the z13 has lots of additional capability and functions along with the updated compilers to increase the speed to allow you to provide more function faster, COBOL improvements using the new system hardware, Java improvements to be able to do more Java development on the mainframe, as well as significant memory availability changes.

    So, with the combination of the system, you can look at it as the best Linux environment that you can use for your cloud environment, so you can have—use Linux on System z to provide your Linux environment for your front end applications, and then, looking at z/OS, you can start to take advantage of this new memory that’s available to increase and improve your performance from a caching standpoint, numerous other things from a performance standpoint with the new compilers, and the mobile connectivity into the system. If we think about the fact that that could drive huge numbers of transactions—could drive huge numbers of transactions—we get the mainframe as the perfect platform to handle that variable load.

    So you never know—you know, I guess if you’re a retailer you know if it’s Thanksgiving or near Christmas it spikes, but many times, you don’t know where the spike’s gonna come, so it’s important to have that capacity on demand, to have that variability, and so the system plays very well.

    I think there are a lot of clients and a lot of organizations that are taking a new look at the mainframe of the latest z13 because of its capability, because of its enhancements from a memory standpoint, and because they think—you know, reality. People are realizing the mainframe is not going anywhere, and it really is the best platform for those high transaction systems and allows you to consolidate things together in a Linux platform. So it’s a great advantage that customers were already using we they have, and it’s something other customers are looking at to do, “You know, I can take advantage of that as well.”

    Alan: Okay. Rosalind, again—I’m sorry to keep saying this, but I’m trying to keep it short for our listeners, and relevant, but there’s just so much here. So you’re constantly out talking to clients that utilizing mainframes, and kind of living this devops and mobile to mainframe way of doing business—can you give me two or three quick examples of companies that are, that you think are doing it right?

    Rosalind: So, if we look at the industry and we look at the publicly available references, Nationwide is one of them that’s been out talking and describing their devops transformation and how they’re exploiting the fact that they’ve brought their teams together to provide value faster in the environment. We can look at Fidelity, who’s talked about their improved deployment capability and their improvements overall in their environment. Or, one of the examples I like that Walmart and their example of using services on the mainframe to actually provide infrastructure services to all their distributed applications from a caching service.

    And so there are numbers of good examples that talk externally, and then there are a whole bunch more examples who consider their transformation to devops a business advantage. They see that, by transforming to devops, they’re getting a leg up on their competition, and so they’re not as willing to let us use their names—but there are lots of wonderful examples of people who have transitioned and who are getting the value out of it, including IBM itself. We have numbers of examples that we provide to show our development process significantly improving and breaking down the silos within our own organizations and improving our ability to deliver.

    Alan: Excellent. Rosalind, I think this was very helpful, as is the book—a great guide for, as you mentioned earlier, both executive managers and practitioners.

    What about you, Rosalind? You’ve had such a successful and storied career—what’s next? What’s next for Rosalind?

    Rosalind: Yeah, so the next thing next week, actually, I’ll share. So, next week, we have one of the major user conferences or the major user conference happening in Orlando. And, as part of SHARE, obviously, we talk about mainframes and development activity as well as lots of different topics, and I’m looking forward to that in particular, because we’re doing a series on mainframe and mobile. More specifically, we’re doing a discussion about hooking Bluemix, our development app platform as a service along with IBM devops services to the back ends, and helping show the relevance of Bluemix to mainframe environment through a series of sessions as well as showing System z as the new cloud disruptor, and there are numerous sessions by other clients like Walmart who will be speaking.

    And so it’s a great opportunity for me to, first to hear stories from our clients as well as to provide some additional sessions for our clients and show what we’re doing, and it will be my first opportunity to have hard copies of this book and do a book signing for any of the client who are there.

    Alan: That’s what I was gonna say—there’ll be plenty of copies of the book there available and signed by yourself.

    Rosalind: Absolutely.

    Alan: Great. Okay, we’re gonna—I think we’re gonna call it a wrap here, Rosalind, and thank you so much for your time. I know you’re busy and I appreciate it. Rosalind Radcliffe, author of Mobile to Mainframe DevOps for Dummies, available now for download or if you’re attending SHARE in Orlando next week, you can get an autographed copy. Rosalind, thank you so much for your gracious time and spending some time with us today. We hope to—you know, best of luck with the great book, highly recommended, and we hope to have you back here soon.

    Rosalind: Thank you for having me, and I’m happy to come back and talk to your audience whenever is appropriate.

    Alan: Okay. Rosalind Radcliffe, IBM, and author of Mobile to Mainframe DevOps for Dummies. This is Alan Shimel for devopsy.kinsta.cloud, and thank you for listening into this DevOps Chat, and join us again soon for another one. Have a great day.

    That’s a wrap on this DevOps Chat. If you would like to be interviewed for a DevOps Chat please contact me at editor@devops.com

  • Q&A with Mark Carrizosa of Soha Systems on secure transition to DevOps and cloud computing

    Q&A with Mark Carrizosa of Soha Systems on secure transition to DevOps and cloud computing

    We recently spoke with Mark Carrizosa, vice president of security at secure application delivery service provider Soha Systems about the trends he sees with enterprises moving to cloud services. Prior to recently joining Soha Systems, Carrizosa held the position of principal security architect at Walmart where he developed and implemented the company’s global e-commerce security architecture framework. Prior to Walmart, Carrizosa held security positions at companies including Wells Fargo, where he analyzed the company’s infrastructure and application compliance to improve the security of both customer-facing and internal systems. Before that, Carrizosa held positions at Freeport-McMoran and PetSmart. This interview has been edited for brevity.

    devopsy.kinsta.cloud: With the rapid move to DevOps and cloud, are there opportunities to improve automation and for enterprises to do more with less? Or is DevOps moving so fast that there are additional challenges being created that outweigh some of the benefits?

    Carrizosa: In my opinion, and in my experience, particularly over the last few years in dealing with predominately DevOps shops, the challenges that we faced were not necessarily “can we automate something,” rather it’s “should we automate something.” There are absolutely some things that should not be left entirely out of the automation stream, but should have controls setup as a requirement at a staging gate. For example, you can automate the dynamic scanning your application for vulnerabilities, but what you also need is somebody to actually look at those applications and manually verify and make sense of the reports. These are key components in deploying and delivering secure applications.

    There are also ways to expedite processes by integrating certain security frameworks into your workflow, providing the right training, and also creating a shift in your culture. And DevOps, for the most part, is a good thing. It allows organizations to rapidly come to market.

    It’s also common in DevOps to have contentions between security and IT. The security group says “No, you can’t do this, it’s going to hurt us.” While the engineers say “We need this to push this out.” How well organizations manage these relationships is a mixed bag. But there is a formula for doing it successfully, and it is all about ingraining security into the culture, into the operations, so that you come out with a secure product and not have to remediate it once it’s done.

    devopsy.kinsta.cloud: When you’re constantly iterating and changing your infrastructure and deploying new apps and updates, how does that affect aspects of security that can’t be automated, such as threat modeling applications before they are built or changes are put in?

    Carrizosa: Threat modeling, while a new term, it’s not a new concept. If you think about risk management, typically audits are done at a point in time. But very good information assurance programs not only audit a point in time, but they implement a continuous model of checks and balances. So should threat modeling.

    Threat modeling needs to happen at inception to ensure that the concept is sound and the methodology is acceptable from a security perspective. But there should also be some levels of checks and balances to ensure that the baseline, or security posture, is maintained throughout the entire change management cycle from inception all the way to delivery.

    These are some of the things that can be embedded within DevOps and Agile. Microsoft has a very good, secure lifecycle management methodology that incorporates various elements of security checks throughout the entire development lifecycle. It’s something like this that needs to be included within these operations to ensure that every step you take has some level of checks and balances, whether it be automated or manual, to ensure that the process of an application or an environment is up to what organizations are requiring.

    devopsy.kinsta.cloud: There’s still considerable interest out there when it comes to how companies are meeting the challenges of moving to cloud services. Are there common threads you see out there when it comes to the challenges enterprises face when moving to cloud services?

    Carrizosa: Yes, absolutely, and one of the key factors is that organizations are looking for ways to securely move to the cloud, or move to a more shared compute environment while still maintaining the control and the reduction of risk that they are used to internally. I spent the majority of my career dealing with these topics from an enterprise level. Most recently at Walmart E-commerce, but I’ve also done the same for PetSmart, Wells Fargo, and some leading industrial companies throughout the industry.

    Some of the challenges that I faced have to do with public exposure. You have to deal with migrating from on-premises to cloud, and dealing with BYOD enterprise users. There are a number of potentially sensitive customer-facing applications or data sets that organizations are a little hesitant to move to, particularly at large organizations.

    Those large organizations are used to doing things a certain way. Time and time again I’ve heard the phrase, “but we’ve always done it this way.” That in essence could be some of the downfall, or some of the hesitance with these organizations in moving to the cloud, because they are not absolutely sure that they will maintain the control and the effectiveness for environments that they can’t manage.

    That’s what Soha is about. Soha allows these organizations to make that next step, to be able to take advantage of these cloud benefits, or even take advantage of some of the cost overhead and the security controls that they’re typically having to address at a high rate of cost and a great deal of effort.

    devopsy.kinsta.cloud: Broadly, considering a lot of the credit card and other significant breaches that have occurred in the past decade, do you think the sense of control enterprises have about how well their security and governance efforts are doing is illusionary?

    Carrizosa: Well, there’s that old adage of, “it’s never ‘if,’ it’s always ‘when.’ These recent breaches, for instance, are not necessarily based on the types of controls that organizations have, but a lot of times legacy controls or legacy approaches have always seemed to be good enough. And until there is some sort of catalyst to effect change, organizations aren’t necessarily going to stick their necks out. You have CIOs saying, “We do this, we do this, and we do this,” because that’s what they’ve always known. It’s time to now shift to a more open model. With that comes many risks, but in order to do so, there needs to be a fundamental change in the methodology of how organizations are tackling security.

  • Will DevOps Kill Outsourcing?: Part 3

    Will DevOps Kill Outsourcing?: Part 3

    Part 3: What’s the differentiator? Understanding how to balance build vs. buy

    (Check out Part 1 and Part 2 of the series Will DevOps Kill Outsourcing?)

    The DevOps movement has spurred a lot of organizations to reevaluate their IT outsourcing strategies. But the reality is that there will be no cataclysmic shift of insourcing. Sure, there will be plenty stand-out case studies and successes among rapid first adopters in the swing away from massive outsourcing. But like all of the biggest sea changes in IT, things will happen gradually when we look across the industry.

    “At the moment, it isn’t necessarily  that enterprises are bringing development back in-house – instead what  we’ve seen is that larger organizations attempt to adopt DevOps and stand  up new teams for new applications in-house, rather than contracting those functions out as they might have done in the past,” says Dan Cornell, CTO of Denim Group. “So, over time the center of gravity will be shifting back toward in-house development. But that will take time.”

    And that won’t even mean that over time DevOps will completely sound the death knell over outsourcing. Most experts believe it’ll always play a part in the IT ecosystem.

    As Alex Henthorn-Iwane of QualiSystems says, he’s observed among customers that even when they bring a lot of functions back in house in order to support DevOps, these companies are still keeping major development processes outsourced. They’re just finding a way to fold them into new processes.

    “So far, it would seem that the pieces of the puzzle that are insourced are the strategic glue pieces,” he says. “There is still a lot of dependence on outsourced, contracted or vendor-delivered services and technology in our customer base.”

    In order to better fit outsourcing engagements into a DevOps-enabled enterprise, organizations will have to get smarter about how they construct their relationships with outside support. It’ll need to be done with flexibility top of mind, says Jeff Gallimore, founding partner at Excella Consulting.

    “They’ll contemplate how that support will integrate with the rest of their staff and work with those who can and do collaborate with their staff. Contracts will be more flexible and accommodating of change,” he says. “That could mean smaller, lightweight, short-term contracts or contracts that provide simple, trust-based change mechanisms.”

    It’ll also require organizations to think carefully about the balance between building, buying and outsourcing the technology that they’re delivering.

    “A  rule of thumb in IT is to insource the most valuable core competencies of the company,” says Andrew Storms, vice president of services for New Context, who explains that’s easier said than done.

    The problem is that as the pendulum shifts to insourcing many people are “poorly assessing which software is the differentiator,” says Theo Schlossnagle, founder of Circonus. There’s a point at which it doesn’t make sense to build something, otherwise everyone would be building it all themselves instead of using off-the-shelf software.  In his mind, the majority of IT effort today is spent integrating, not innovating.

    “When you conflate integration with innovation you lose,” he says. “The goal should be to buy over build when possible, but innovate in-house precisely those things that are core to your business that can change how you compete in your market.”

     

  • The Art of DevOps

    The Art of DevOps

    This is the third in a series of posts on DevOps. The first written by my colleague Lee Reid was titled The Simple Math of DevOps. The second The Calculus of DevOps was written by IBM client, and my friend Carmen DeArdo of Nationwide. Lee introduced mathematically improving delivery throughput by leveraging DevOps to improve Trust. And Carmen used Calculus to imply that the business value of IT can be improved by adopting DevOps to increase the frequency of releases. In my post I would like to visit the art of DevOps , or the art of adopting DevOps by picking up right where Carmen left off – by looking at the culture side of adopting DevOps.

    Lee and Carmen have already alluded to some basic premises behind DevOps as an approach – reducing batch sizeand improving collaboration. These result in reducing complexity, increasing throughput, and improving trust. Let’s talk about how to get there.

    As I have worked with customers adopting DevOps, across company sizes, across industries and countries, there are four common threads that make DevOps adoption successful, leveraging all three aspects of DevOps adoption – culture, process and automation. These are:

    1. Reduce batch size: The most effective way to manage risk and quality, while increasing speed is to reduce the batch size in each iteration or ‘sprint’. This is a mind shift to release smaller, more frequent new versions. Where it is not possible to release new versions that frequently to customers, release small batches to a pre-production area. The deliverable in pre-production is tested and made customer-ready, and then released to the customer at formal release dates. As Lee and Carmen have both discussed, reducing batch size is a pre-requisite to improving both trust and business value.
    2. Shift-left Operational engagement: Get operations engaged right from the beginning of a project/initiative. This has been a core principle of DevOps. Do not leave Ops in a silo that one throws code over the wall to, but have them engaged in the development process, right from requirement inception stage. This allows Ops to have visibility into what is coming from Dev; allowing them to deliver the right production-like environments, as and when needed to Dev and Test teams. It also allows Ops to shift operational concerns left, left into the minds of developers, making them more Ops conscious and engaged in what happens after they hand-off to Ops.
    3. Continuous funding: This is a significant change in an organizations funding model to enable continuous availability and engagement of SMEs and business functions, previously not engaged on a continuous basis – like security, legal, marketing, etc. Carmen in his post mentioned several examples of ‘waiting for…’ work, someone else to do something and environments. Another ‘waiting for’ in enterprises is for funding. Funding is typically provided in a waterfall manner, with specific hard dates (Months, quarters, fiscal year) and gates, not suitable for a Continuous Delivery model. Funding too should be continuous.
    4. Create a ‘Product Management’ team: This team includes a Designer, Development lead, operations lead and an Architect at the minimum (4-in-box). They own the ‘product’ through its entire lifecycle, and beyond transient projects. They are responsible for long-term thinking, design thinking, evolutionary architectural thinking, and overall ownership of the product, from concept to end-of-life.
    5. Setting up a DevOps Center of Excellence (CoE): This center of excellence is not an administrative organization or a ‘tools/enablement group’, but a place where DevOps adoptees come to learn from each other and share expertise and lessons learnt. As organizations adopt and scale DevOps adoption, this CoE also becomes a source of DevOps coaches, helping teams and programs adopt DevOps, and own the organizations DevOps framework – their own flavor of DevOps.

    Adopting DevOps is an art. It is not as simple as hiring a consultant who can show how to improve processes; it is not just buying and adopting tools to automate manual tasks; and it is not going through ‘fall-back-into-the-arms-of-the-person-behind-you’ exercises to build trust. It is a combination of all three – process improvement, organizational and cultural change, and automation with tools to replace manual processes. Adopting these in any enterprise, outside of startups, requires overcoming organizational inertia. By changing culture not by edict, but by showing the need and value of change. By building trust, not through meetings, but with improved communication and transparency. By improving business value, not by measuring mandated KPIs, but by improving organizational agility and throughput. Overcoming organizational inertia, by delivering towards a common goal for the business, irrespective of where in the organization one is, and what role one has. By developing a culture where everyone takes responsibility of delivering value to the business.

    Watch the webcast series hosted by devopsy.kinsta.cloud in partnership with IBM or download a copy of DevOps for Dummies book for more information.

    About the Author/ Sanjeev Sharma

    SanjeevSanjeev Sharma, CTO and Distinguished Engineer – DevOps Technical Sales and Adoption, IBM Cloud Unit, is a 20-year veteran of the software industry with expertise in DevOps, Mobile Development and UX, Lean and Agile Transformation, Application Lifecycle Management and Software Supply Chains. He is a DevOps Thought Leader at IBM and speaks regularly at conferences. He has written several papers and is the author of the DevOps for Dummies book.

     

    Contact Sanjeev on linkedintwitter

  • DevOps killing outsourcing? Another point of view

    DevOps killing outsourcing? Another point of view

    After reviewing the articles (here and here) on DevOps driving the end to outsourcing I felt it would be constructive to provide an alternative point of view.  The premise of the article is that because DevOps requires close collaboration between development and operations that it would be difficult if not impossible to effectively implement DevOps in a heavily outsourced environment.  Additionally the productivity advantages of DevOps would help eliminate the need for outsourcing.  Therefore, organizations wishing to see the advantages of DevOps should move away from outsourcing.  While I can see the advantages of that approach, I also think that companies that have to live with outsourcing can’t ignore the benefits from implementing DevOps principles with a well-designed deployment pipeline.

    From my perspective, companies looking to implement DevOps first need to start by understanding their architecture because it has such a large influence on how to effectively implement DevOps.  If they have loosely coupled architectures that enable small teams to independently develop, qualify, and release code then they should look to the world of unicorns for how to implement DevOps.  They should look at integrating operational people onto the development team and work to evolve the culture by blurring the lines and responsibilities between the two groups.  This feels like a fairly straightforward process that many unicorns have proved to be very successful.  For these types of organizations, I tend to agree with the articles recommendations that DevOps would work better without outsourcing.

    The problem is that most large traditional organizations looking to implement DevOps don’t have the benefit of an architecture that enables small nimble teams to work independently.  They typically have very tightly coupled legacy architectures that require 100-1000s of engineers to work closely together to develop, qualify, and deploy complex integrated systems.  Ideally, they would re-architect their applications so they could see the benefits of nimble independent teams.  The reality though is that this is just not practical for most traditional organizations in the short-term.  Additionally, they can’t wait for the re-architecture before they start realizing the advantages that DevOps principles can provide with a well-designed deployment pipeline.

    For these organizations implementing DevOps principles (the ability to release code to the customer on a more frequent basis while maintaining or improving stability and quality) is more about creating a well-designed deployment pipeline that builds up a more stable enterprise systems on a regular basis so it is much easier to release the code on a more frequent basis.  This is done by creating a deployment pipeline that integrates the code across the enterprise system on a much more frequent basis with automated testing to ensure that new functionality is not breaking existing code and the code quality is kept much closer to release quality.

    From my perspective this approach to DevOps is rather different from the more unicorn type approach described in this article.  It though does address the biggest opportunity for improvement that does exist in more large traditional organizations which is coordinating the work across teams.  In these cases the working code in the deployment pipeline is the forcing function used to coordinate work and ensure alignment across the organization.  If the code from different teams won’t work together or it won’t work in production, the organization is forced to fix those issues immediately before too much code is written that will not work together in a production environment.  Addressing these issues early and often in a deployment pipeline is one of the most important things large traditional organizations can and should be doing to improve the effectiveness of their development and deployment processes.

    These benefits are even more pronounced when working in organizations that have outsource development across multiple companies around the world.  Ensuring the different vendors don’t go off track and create code that won’t work together in production is critical and a well-designed deployment pipeline is a critical tool for coordinating development across different outsourced organizations in traditional tightly coupled systems.  For these types of outsourced organization, DevOps principles while different are almost more important than they are for companies that do all their development internally.

    About the Author/ Gary Gruver

    gary gruverGary Gruver is an executive with a proven track record of leading Large-Scale Agile transformations and co-author of “A Practical Approach to Large-Scale Agile Development” and the new book, “Leading the Transformation: Applying Agile and DevOps Principles at Scale.” He is currently working to help organizations with their transformations after successfully leading two large transitions at HP and Macy’s.  As the Director of Engineering at HP, he led a large organization (400+ developers) on a journey from waterfall to agile development. At Macy’s.com, as the VP of QE, Release, and Operations, he led the transition to Continuous Delivery.  Reach him on twitter at: @GRUVERGary

  • Will DevOps Kill IT Outsourcing?: Part 2

    Will DevOps Kill IT Outsourcing?: Part 2

    Part 2: Continuous delivery tool chain efficiency > Outsourcing savings

    (Check out Part 1 of the series Will DevOps Kill IT Outsourcing?)

    Experts on digital disruption and DevOps practices are vocal in their belief that DevOps and traditional outsourcing models don’t mix well.

    “Adopting DevOps requires organizations to erase the barriers between development and operations teams,” says Dan Cornell, CTO of Denim Group. “This is hard enough to do within a single organization and nearly impossible to do across organization boundaries.”

    If push came to shove and an organization needed to justify an either-or decision for DevOps over outsourcing, the argument would likely revolve largely around business value. Continuous delivery makes it possible to move to market more quickly, develop products better aligned to customer sentiment and kick the pants out of competitors who don’t do the same. That was the impetus behind the shift at GE Capital. Last year the firm’s CIO Jim Fowler said he was looking to significantly reduce IT outsourcing and shift toward more Agile teams. Earlier this summer Matt Merchant, former global managing director of DevOps for GE Capital gave devopsy.kinsta.cloud a snapshot into how this is driving innovation. (Ed. Note: Merchant suddenly passed on this summer. Our interview was just prior to this tragic event.) He explained how the company was able shift customer-facing mobile app development from a six- to eight-week release cycle to twice weekly.

    But the decision to dump outsourcing in favor of supporting DevOps practices within a more centralized IT group doesn’t just have topline revenue and innovation benefits. The upside presents itself in the bottom line as well.

    In many ways, we can chalk that up to the fact that the automation and cloud technology that facilitates continuous delivery is light years ahead of where it was when belt-tightening outsourcing deals crescendoed following the 2008 financial crisis. As things stand, the cloud has enabled IT to decouple infrastructure outsourcing from operational and process outsourcing.

    “Companies today realize they can achieve many of the cost efficiencies that outsourcing was originally intended to achieve by leveraging cloud technologies,” says Thomas Enochs, vice president of customer success at Chef . “There is a general trend towards leveraging cloud services rather than cheap labor to achieve the scale, speed, and flexibility they desire.”
    The fact is that many an outsourcing deal was born in a day when the tools of development were slow to deploy and expensive.

    “DevOps practices and modern software tools have drastically reduced the time and cost required to develop custom applications,” says Bernard Sanders, CTO of CloudBolt Software. “In the early 2000s, the step of just getting the servers and infrastructure set up for a new app could be a multi-week or -month chore.”

    Virtualization vendors, cloud providers and self-service automation have all made it possible for developers to get easy and affordable access to the infrastructure they need when they need it, Sanders says. And then there’s the advances in deployment pipeline automation that are seriously streamlining hand-offs over the course of the software development lifecycle. It’s all adding up to added efficiency and reduced cost of development and deployment.

    “In the future, the overhead required to build custom apps will be driven to near zero, and enterprises will be able to in-source this development, retaining this function that has become key to enterprises’ brand identity, product offerings, and customer experience,” Sanders says.

    Even now, though, the DevOps toolchain is completely blowing up a lot of the financial models that initially drove IT departments to aggressively outsource. While many outsourcing deals continue to be renewed without reviewing old assumptions, this is starting to change.

    “We have seen cases where outsourced functions like automating test or other processes has been brought back in house because equipped with the right approach and tooling, the internal team could achieve better results, but also because the automation work was a key building-block to a longer-term DevOps plan,” says Alex Henthorn-Iwane of QualiSystems.

  • Part 2: Meeting relentless mobile app demand

    Part 2: Meeting relentless mobile app demand

    As we discussed in  Meeting the Relentless Mobile App Demand of the Enterprise, the enterprise thirst for mobile apps will far outstretch what enterprise internal development teams will be in a position to produce.

    Developers will need every edge provided to them in order to help their enterprise success. And there’s no doubt that IT teams need to be agile and move as quickly as possible and this is as true with mobile development than anywhere. By not being able to meet the increasing demand for enterprise mobile apps, enterprises can’t be as effective and productive as they need to be. That creates substantial business opportunity costs.

    Here are some ways I think enterprises can improve the mobile app development efforts, in addition to what Gartner suggested, detailed in our part 1:

    Adopt agility. Enterprise IT is changing rapidly. The tight collaboration with development and operations teams, drive for agility, continuous development and other approaches that are increasingly mainstream are pushing applications out into production, and updating existing ones, more quickly than ever was before possible. Not only do successful DevOps organizations have short app backlogs, they are more innovative. Our special guest contributor Matt Selheimer wrote am insightful series that culminated with DevOps with purpose: ACT-ing with greater agility that details how to be more agile through DevOps practices.

    The more agile your organization, the more swiftly they can re-adjust and move always be producing the apps that matter and those that will drive the greatest business impact.

    Leverage APIs. Instead of building apps from scratch and creating more data silos, take a page from Gartner’s advice on mode 1 which is building infrastructure and APIs. Most existing large enterprises have enormous data and application and database silos. One effective way, when possible, to unleash that data and reduce silos is through APIs. APIs are the most straightforward way to build the capabilities the business needs through    extending the utility of existing applications.

    Leverage the cloud to the hilt. Whenever possible, it’s time to go cloud first. It’s time to gate legacy on-premises systems and maintain them until they can be displaced. This will include public, private, and hybrid cloud architectures – but the more rapidly legacy on-premises systems can be retired the more agile IT can be.

    Our post, Three tips for maximizing efficiency in the age of the hybrid cloud environment, provides insight into how to manage hybrid cloud environments.

    Choose cloud and development platforms carefully. There are a number of other critical platform questions, too: Can the data be provided wherever the user needs it? Does it help alleviate security, privacy, and regulatory compliance demands? And can the platform help with role-based identity management and provide for auditable access control?  All of these things being provided as utility help expedite application development and clear your app backlog.

    The more people in your organization who can develop the better. This could come in the form of training non-developers to build some of the app capabilities they need in cloud platforms and with very high level coding tools. It’s easier now than ever before for anyone to create business process workflows with hardly any code.

    Be MVP lean. The Minimum Viable Product (MVP) is a viable way to identify mobile apps that are in need and will likely provide the most immediate value. Simply defined, the MVP consists of what is only necessary to get the task done and little more. If the app is successful, it can be improved upon and iterated based on user feedback and business need.

    One way DevOps helps to achieve this is through splicing development time so many apps can be worked on incrementally, and the MVP concept is ideal for this type of workflow. It makes it easy to re-prioritize apps and new incremental work on existing ones based on pressing business priorities.

    I’m sure there are other ways to help make mobile app development efforts both effective and strategic to the enterprise rather than fire-fighting app demand. If you have any ideas, we’d like to hear them in the comments below. What strategies, tools, techniques are your organization using to increase mobile app development efficiency?