Tag: it

  • Bringing the Database into the DevOps Fold

    Bringing the Database into the DevOps Fold

    In my last post on devopsy.kinsta.cloud I asked the question, “Where is the DBA in the DevOps Conversation?” I have wonderful news. I’ve found them! Having not been offered a seat at the table with everyone else, the DBAs have decided to have their own party in the form of a survey and corresponding report by Unisphere Research for the Independent Oracle Users’ Group.

    Until now so much of the research, literature, and web content on the topic of DevOps has been completely devoid of talk about the database and DBAs. The oversight was significant and troubling given the immense strategic business value of any organization’s ever growing store of data. The IOUG report does an excellent job of framing the case for DevOps in terms of the special considerations required when trying to adapt to the lightning fast pace of change in modern IT.

    For me, the biggest take away from the report is that DBAs and their managers are feeling the pain of increased release velocity acutely.
    Interestingly, while the age of automation and cloud may be upon us, an increasing number of database managers and professionals report that they are being mired in manual processes. More than one-third cited this as a challenge, up a dramatic 162% from four years ago.
    There’s no question that companies large and small understand that releasing quality services and features based on market demand at a faster rate than your competition keeps your organization on top. It’s also apparent that product development and most of IT operations have made the necessary investments in process modification and the automation necessary to truly achieve faster delivery. Unfortunately the report confirms what the good folks at my company, Datical, have been saying all along. The lack of safe, intelligent deployment automation options for the database is starting to limit the potential gains of DevOps implementation…and the data team knows it. But it’s not the actual script execution that takes so much time. It’s all the time spent before that maintenance window making sure that security isn’t being compromised, that the change is compliant with external regulations and corporate standards, and that it won’t negatively affect your data.

    Today’s manual database operations, processes, and approval time are among the causes of delays holding up the real-time enterprise, many database managers and professionals admit. Frantic development cycles and the accelerated pace of business innovation requires that data and insights be available at a moment’s notice. Close to 41% of respondents report that it takes a week or more to approve change requests, as well as to configure new databases for key purposes, even for testing.

    To safely reduce these cycle times a DevOps solution for database deployments has to harness the expertise and experience of an organization’s DBAs to fuel intelligent, environment-aware automated validation of these change requests. The automation can’t simply parse the SQL script looking for patterns that may be problematic. It must be able to evaluate all 5 W’s associated with the change and make the correct determination as to whether it is acceptable or needs further review. By focusing the valuable finite resource that is your organization’s DBAs on only those changes that need their special attention, you’ll reap even greater rewards from your DevOps investments.

    I’ve just scratched the surface of what’s available in this report and I highly recommend you read and share it with the DBAs at your company. The survey covers responses from folks in every size company and at every level of the database team. It is full of facts and observations that will be readily familiar to any DevOps enthusiast or practitioner. DBAs, IT, Developers, and the business are now all speaking the same language when it comes to DevOps. Do what you can in your organization to make sure they are speaking that language to each other.

    About the Author/Pete Pickerill

    Pete Pickerill is Vice President of Products and Co-founder of Datical. Pete is a software industry veteran who has built his career in Austin’s technology sector. Prior to co-founding Datical, he was employee number one at Phurnace Software and helped lead the company to a high profile acquisition by BMC Software, Inc. His ability to understand product demands from a customer’s perspective and translate those demands into actionable product and development plans has led to expanded duties at every company for which he’s worked.

  • Choosing a Mobile Test Automation Solution: What You Need to Know

    Choosing a Mobile Test Automation Solution: What You Need to Know

    Organizations today rely more and more heavily on mobile apps to drive their business. In fact, many companies are already seeing more than half of their web traffic coming in via mobile devices. In some cases, their mobile app is the only way customers interact with their products.

    It’s no surprise, then, that developing, testing, and releasing quality mobile apps quickly and efficiently is a high priority for most organizations—as it should be! Fortunately, mobile development tools are evolving to meet these needs, with modern dev teams having access to better test automation than ever before.

    Of course, the effectiveness of a mobile testing process is only as good as the technology behind it. This makes it even more crucial for organizations to know what factors are most important to take into account when choosing or building a robust mobile testing solution. Below, we outline some key things to consider:

    Native, Hybrid, and Mobile Web Support
    Modern mobile applications come in three different flavors: native, hybrid and web. Native apps are built using the vendor-provided SDKs. Hybrid apps run some or all of their functionality inside a webview embedded in a native app. Finally, mobile web apps are simply mobile-optimized website that users access through their mobile browsers. While there is a growing trend towards mobile web and hybrid applications (rather than native), to ensure maximum flexibility and impact of your QA solution, it’s important that you choose a tool that supports all three kinds of apps.

    On-Demand Cloud Testing
    With QA teams becoming more and more distributed, it makes sense to ensure that your mobile application testing solution includes a cloud component. Leveraging an automation cloud enables teams to use organize around a single implementation of test architecture, with devices and test result data accessible from anywhere in the world. You can spend your time worrying about your testsuite, not the cost and maintenance headaches associated with keeping up multiple home-grown device grids and architectural patterns.

    Automation
    When it comes to mobile testing, automation is essential. Choosing the right automation frameworks (Selenium, Appium, etc…) and test tools (languages, test runners, etc…) can be a challenge, and it’s important to think about all the factors involved in getting a solid mobile build process going, relative to the expertise your QA team possesses. What kinds of user flows will you need to automate, and can the automation tool support them? Do you want automation code mixed in with your app code or cleanly separate? Is automation support available for the languages and tools you know best? Think about building a testsuite with the same level of architectural foresight as you would building an app.

    Integration with Key Support Systems
    It’s also important to consider what level of integration is needed with support systems in your environment – whether it’s a test management system, a CI server, or defect tracking system. A strong solution will be able to easily integrate with all of these other systems, perhaps all the way down to the IDEs your developers are using.

    Cross Platform Support
    With the majority of applications being developed for iOS and Android, it’s a minimum requirement for your mobile application testing solution to support automation on both platforms. Of course, this will no doubt expand as you consider other devices and operating systems such as Windows, FirefoxOS, etc…, based on your customer base.

    Scalability
    As the number of device types and operating systems being tested increases, it becomes increasingly important that your test architecture is able to scale automatically based on the number of tests you want to run and the amount of time you want your build to take. Building your automation on a framework like the open source Appium project is a good architectural investment; Appium’s client/server architecture makes it easy to build a testsuite than can automatically utilize a cloud service as your need for more emulators, simulators, and real devices grows.

    The proliferation of web and mobile applications across a myriad of devices and operating systems is fueling a demand for faster and faster delivery of software experiences, without any sacrifice of quality. Today’s leading software companies know that successful apps are built on the foundation of their mobile application testing processes and tools. By keeping in mind the key features mentioned above, organizations can work towards building and identifying the best testing solution for them. The QA process should be a breeze, rather than a hassle.

    About the Author/Jonathan Lipps

    jlipps Jonathan Lipps serves as the director of ecosystem and integrations at Sauce Labs, where he leads a team of developers to ensure that the open source ecosystem surrounding the company’s core products is always maintained. He is a frequent speaker on automated web and mobile app testing, and holds advanced degrees in Linguistics and Philosophy.  Reach Jonathan on twitter.

     

  • George Jetson Automation: Chasing the Dream

    George Jetson Automation: Chasing the Dream

    “His job was one simple thing—press a button. That’s all he had to do; press one button and sit back.” – Joe Barbera

    I wanted to be George Jetson when I grew up. Back in the days when watching Saturday morning cartoons in footed pajamas was the high point of my week, George’s life looked as sweet as a bowl of Super Sugar Crisp cereal. Flying cars, robots, and a two-hour-a-day, three-day work week lightened even further by 100% push-button automation.

    jetson_button1

    Contrariwise, my first tech job out of high school was a classic study in manual labor. From 9pm to 5am, I was solitary “Night Backup Operator” for a small data storage company, lone man responsible for continuously swapping reel-to-reel tapes on and off a literal wall of old magnetic drives.

    reels

    It was repetitive, monotonous and boring, and the tapes were prone to jamming and tearing. A lot.

    tapes

    One night I was thumbing through a tech catalog and came across a listing for a new cassette backup system. I mentioned to my boss the following day that our reel drives could potentially be replaced by a unit the size of a large book. He took it to heart, made a purchase, and one evening shortly afterwards I came to work, popped in a blank cassette, hit a button, and kicked back for the next eight hours as 100% of my work was done for me. It was a George Jetson moment. The future had finally arrived. I was blissfully complete.

    They fired me, of course. It actually took them a few weeks to realize that I’d been automated completely out of a job. To their credit, they were appreciative and regretful in parting, but there was hardly any point in paying me to sit on my can reading pulp SF for eight hours every night.

    Regardless, I’ve been chasing that George Jetson moment ever since.

    The magic behind the button

    In the decades since, with a number of (slightly more professional) IT automation projects behind me, I’ve discovered that the “automate-everything” button is usually a lot tougher to achieve, and near-impossible to buy off the shelf. To even get close, you often end up building a significant amount of infrastructure up from scratch.

    But say you could buy a “George Jetson” button; a self-contained, perfect automation solution off the shelf; what do you look for? Setting aside the nuts and bolts of a specific IT problem or project, what does an “automate-everything” button need to do, in essence?

    1.   “Do No Harm”

    At the first sign of an incident, Mr. Spacely (voiced by Mel Blanc, “Man of a Thousand Voices”) pops up and begins motivating with the bellow “JETSONNNNN!”. (I once worked outage calls with an IT director who had the same management style, I kid you not). We don’t want this to happen. So our “automate-everything” button needs, first and foremost, to mitigate risk.

    Security should be the first consideration in risk management, yet it’s an area where (oddly enough) a number of automation solutions fall flat out of the gate. Managed user accounts (ideally, integration with established account management systems), role-based permissions (for pushing the button in various situations, IT environments, and scheduled times), and sensitive information handling should all be covered.

    The ideal automation solution’s back-end infrastructure should be robust, flexible, and professionally engineered. If any pieces are open-source or community-designed, what they do and don’t do should be well-documented, including an understanding of potential situations likely to result in unintended consequences.

    We also want the automation button, once pushed, to never perform the action again if there’s no need to do so. This is idempotence, a valuable concept that’s been around for a long time but has risen to prominence over the last year. Idempotence is particularly important once you start to consider auto-remediation (why push the button manually if it can run automatically?), and efficiency (why spend effort building an automation action that can only be run once?).

    2.   “CYA”

    “Cover Your Automation.” George isn’t particularly smart for a computer operator. But maybe he doesn’t need to be. Let’s say he’s supported by a lower floor full of smart engineering robots. The robots set up the automation actions and push them into an approval queue with just enough information to make a decision on whether an action is needed or not.

    George evaluates each situation and pushes the button if everything looks good to him. Now, the “automate-everything” button becomes more of an “approval” button in a formal change management system. There might be more approvers besides George, each laying eyes on the proposed automation action and passing it along to the next approver as appropriate.

    Most operators aren’t as dumb as George, but everybody has “dumb moments”. Change management needs to be a core part of any automation system.

    Accountability supported by thorough logging is also a key “CYA” aspect of the ideal automation system. “What” happened, “when” did it happen, “who” did it, and so on… if your automation system doesn’t track all essential information, you might not be able to return to your job after Spacely mistakenly fires you.

    3.    “KISS”

    “Keep It Simple, Stupid.” Dealing with complex automation workflows is tricky if they involve a lot of step-by-step actions, as they traditionally have in the past. When complexity clashes with modern, large-scale IT environments, situations arise that are literally impossible to manage manually. “Scale x Complexity > Effort” is the equation desperately slashed across whiteboards in planning meetings these days. Modern automation systems often attempt to reduce complexity and equalize scale through a form of orchestrated states.

    The idea depends on two parts. A desired state is a recent Microsoft-championed concept where the steps required to reach an end result are black boxed in favor of defining a system’s state itself. The usual example: rather than considering a step-by-step recipe for a birthday cake, you describe “a white cake with pink frosting” as your desired outcome and pop your request into an automated system to make it happen. Recent configuration management solutions have made excellent headway in this area.

    But desired states aren’t enough in and of themselves. They almost always need to be orchestrated to reach the final goal. An orchestrated states effort runs more along the lines of: “I need a white cake with pink frosting at the same time as a bowl of orange punch, before the time of the birthday party, but after the house cleaning. Also, yellow balloons.” Real-life IT infrastructure requires at least this level of complexity and timing.

    For a complete “automate-everything” solution, our ubiquitous button needs to orchestrate the states of all necessary systems and services in a way that’s easy for George, our hapless operator, to process, and considers both transitory states and final states as well as the interactions between them.

    jetson_button2

    When evaluating whether an IT automation solution is right for you, you may not be able to find the ideal “automate-everything” button, but make sure you consider it from these three perspectives. The perfect solution may, in the end, just be a dream to be chased by the laziest as we move from one IT automation project to the next. But it sure is fun seeing how close we can come to that blissful, futuristic George Jetson moment.

  • DevOps Drives Innovation, Enterprise Differentiation

    DevOps Drives Innovation, Enterprise Differentiation

    It’s hard to believe that it’s been more than a decade since Nicholas Carr wrote his controversial article “Does IT Matter,” where he argued that IT had become such an integral part of business that IT disappeared into the infrastructure in the way roads, rails, electric utilities, and engines have in industry. IT, like such infrastructure, became so commonplace that it no longer provided a competitive advantage.

    While Carr nodded to the transformative nature of cloud computing, he didn’t see the competitive advantage made possible by businesses that could develop rapidly and innovate. And that’s at the heard of what DevOps, and the associated processes and collaboration is all about. And enterprises that are able to identify opportunities and rapidly innovate using IT more effectively than their competitors would succeed.

    However, to succeed, IT investments need to be viewed as more than just ways to cut costs in applications or IT infrastructure. IT has to be looked at as a way to actually drive innovation. And DevOps itself needs to be viewed as more than just a way to reap increased efficiencies out of existing processes and technologies: but as a way to also more tightly couple business needs with IT efforts. One of the most effective ways to do this is to build applications that matter to business users.

    When it comes to building great business applications, enterprises often don’t get apps right – however that is a gap DevOps can help to close. When it comes to building apps, organizations often try to build the same apps on mobile devices that they’ve been providing on desktops for years. Or, they try to build applications that attempt to accomplish too much, and end up being overly complicated and largely unused as a result.

    “Businesses don’t always get apps built right,” says Brian Katz director, head of end user experience and innovation at Sanofi. “In fact it’s common that they don’t. They try to develop complicated apps that people don’t actually use instead of developing apps that users really need,” says Katz.

    “If good app design isn’t part of the equation, all you get is operations and development tools and processes that are optimized to deliver poor app quality,” says Katz. “Design isn’t always part of DevOps, but I think it should be. But design is one of those things that is critical to driving innovation, but people don’t always think about it that way,” he adds.

    One way DevOps can help address app development speed bumps is to make sure that these teams are integrated more closely with those who are designing the apps and know what the end users want to do – and how they want to do it. This is especially true when it comes to mobile development, when users may have seconds to input or grab data while they are on the go.

    Chris Cera, CEO at mobile and web product development firm Arcweb agrees, and says that testing and design are crucial to building the apps users want to use and to driving IT innovation. “You want to test the user interface and get feedback. It’s so crucial to developing the apps that will not only be apps users want to use, but it’s the key to driving innovative design too,” says Cera.

    Those enterprises that do manage to successfully integrate great app design with their DevOps efforts will prove themselves formidable competitors in the years ahead. “The organizations that embrace DevOps are seeing what good happens when the business and IT collaborate, and in the years ahead we will probably see more technology leaders show how IT can lead the organization forward,” says Gene Kim, co-author of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.

    The data are starting to prove such claims valid. According to the 2014 State of DevOps Report from Puppet Labs, DevOps enterprise adoption is increasing and those organizations that embrace DevOps are deploying code 30 times more frequently and with half as many failures as non-DevOps enterprises. That data helps to support the findings of a CA Technologies study published last year, TechInsights Report: What Smart Businesses Know About DevOps, which found that respondents claim to experience a 17 to 23 percent improvement in certain business outcomes, such as increased revenue, and faster time-to-market.

    That all certainly sounds like IT as a way to innovate and differentiate. While the day will come when “IT Doesn’t Matter” – that’s a time that is likely decades away.

  • The fashionable IT crowd

    The fashionable IT crowd

    The IT Crowd

    I was recently reading an article in Marie Claire UK (yes I do read non-nerdy publications, some higher AI should sentence my brain to enter a loop without an exit condition) which explained that women should start learning how to code in order to become successful professionally. That triggered my curiosity and I started to wonder when IT became classy enough to be mentioned in a fashion magazine. This might be the time for a little history.

    Don’t blame Information Technology.

    Once upon a time, well before the internet – yes kids, there was a time where people had to read books to access knowledge – IBM was ruling them all. It was such an important and powerful company that you could likely compare it to Google today. IBM salesmen were to wear suits, ties and an attaché case every day like other any other corporate person and techies had to wear a simple white shirt with an IBM logo on it. IT fashion at that time was pretty much neutral and IT was seen as any other field of work.

    In the early eighties, Bill Gates who started to do business with IBM had a look that would, for some reason, stick with IT people for decades: oversized glasses, poorly shaped and tasteless beige tops with a pair of equally bad looking trousers.

    Steve Jobs on the other hand when not representing his company officially was already seen wearing his now infamous denim and black turtleneck combo. The power of branding.

    How come then that with so many different styles in circulation, one prevailed in people’s minds as the standard geek outfit? Well, in order to understand, we have to broaden our search a bit and we can then realize one thing: in the eighties, almost every person that had an interest in science had poor social skills and or almost no interest in fashion or styling. While this is a gross generalization a quick internet search for images of “nerd 80s style” should demonstrate what I mean.

    Music has changed it all.

    In 2001 Mp3 players had existed for years but were a niche market as their price was too high, their storage capacity too low (one album would fill up a player) and they required a computer and some technical knowledge. Downloading a song was also an obstacle as there was no massively spread peer to peer or legal solutions at that time.

    Then came Apple with its iPod, almost like a piece of art that created curiosity and attraction and offered enough storage space for many albums at once. I think this was the first time the public saw an interest in a computer or mac related device. CDs while hugely popular were impractical – think of carrying more than one of them with you everywhere you go – huge and mostly unreliable for jogging or walking fast.

    People who wanted an mp3 player and who did not own a computer had to get one and access to the internet. The internet which was mostly used by “people who knew” became more and more popular and people started to massively use emails and chats (msn, aim and all those brands which do not exist any longer) and slowly gained the knowledge to use internet in a more efficient way. This led internet providers to offer higher bandwidth and the development of a plethora of websites with ever more content.

    With access to everything at all times, computers gained in popularity and the emergence of smartphones spread the use of internet even a bit further.

    In the mid-2000s, technology, the people traditionally associated with it and their culture then became hip. That was the beginning of the “geek chic” trend, often confused nowadays with the hipster subculture. People started to wear old style clothes such as suspenders and those oversized horn-rimmed glasses. Not adapted to the business world, this trend quickly faded however with the public gaining awareness of things beyond glasses, thanks to popular TV shows such as The Big Bang Theory or Chuck, the geek culture spread widely.

    Finally recommendable

    All those factors contributed to IT becoming less and less a world of “freaks and geeks” and more and more a profession as acceptable and as open to everyone as any other, finally showing up as a recommendation for a professional path in a women’s magazine.

    It was about time.

  • Change your thinking about Change Management

    Change your thinking about Change Management

    Change Management, let’s face it, it’s usually a checklist item and a CYA tool. But in the world of DevOps where change is part of the culture and processes.  Change Management needs to be more than a cost center, and really a way to improve what you are doing. And there is no excuse not to.

    (more…)

  • Meet Infrastructure as Code

    Meet Infrastructure as Code

    Maybe you have already heard the terms “Programmable Infrastructure” and “Infrastructure as code”.  But even if you have not, if you are interested in DevOps it’s something you need to know.   Most new lingo causes me to roll my eyes.  But in this case, it’s not just new lingo, it’s an entirely new concept. Besides making the nerdy feel cool when they say it, these terms describe a new idea of what an application consists of. (more…)