devopsy.kinsta.cloud

Author: contributor

The perfect fit: what to look for when hiring a consultancy group and how to build a lasting relationship

Whether your company is just getting started or has been in business for years, selecting and building the right team makes a significant impact on your output quality, team morale and retention. If you are looking for engineers that are skilled, experienced, and a good cultural fit to step into a new or ongoing technology project, consider hiring a consulting group.

Once you’ve determined that a consultancy group is the right solution for your business, you will need to select a company to work with. But what should you look for when hiring a consultancy group? Make sure you’re choosing the team that is perfect for your company, and how should you manage them once you’ve started working together? A selective, thorough approach to hiring and managing a team will result in exponential benefits for both your product development and overall team morale.

Hiring the Right Team

Look for a dynamic, adaptable and nimble team. While the specs for your project may focus on one aspect today, the next day you may discover the need to pivot in an entirely new direction. Engineers need to understand programming principles and paradigms before being proficient in any language, so make sure that the consultancy group you select has engineers that are skilled enough to easily switch languages and architectures, learn new languages and migrate to different environments, among other things.

Assess candidates holistically.When looking for the best-fit consultancy firm, be sure to evaluate both their technical and soft skills. Carefully assess their technical abilities and make sure that the skills and experience are there. Be sure to also evaluate their soft skills such as attitude, energy, cultural fit, personality, motivation and ethics. If you cannot meet the team you will be working with in-person, try video-conferencing to get to know them face-to-face, which can help with making sure it will be a fit. Lastly, take the time to look into the consultancy group’s track record of success and what current and past clients have said about their work.

Setting Your New Team Up for Success

Prior to beginning the engagement with the consultancy group, be sure to communicate expectations clearly and eliminate as many questions as possible to avoid mistakes and multiple iterations. It can also be very helpful to provide your consultant with a thorough “Requirements” document, wireframes and as much context as possible to help them get up to speed as quickly as possible.

Motivation is also key with any successful software development team and can make or break a project. Make sure that everyone understands and believes in your vision before embarking on a new project. For a longer-term project, consider switching team members between projects and technologies to allow them the opportunity work on something new and keep them engaged in their work.

For teams working remotely in various locations, managers should provide honest, regular and respectful communication with their remote teams to build camaraderie, trust and overall passion for the project. Get the most from your team by leveraging any differences that exist, they may turn out to be your greatest advantage in the end!

Managing your Team

As a manager, it is important to create an environment that allows your engineers to focus on what they do best: building software. Be sure to communicate frequently with the remote teams to answer any questions they may have during the project lifecycle and keep it on track. Use a cooperation platform or Project Management platform to organize and track the technical details of your project. Establish any parameters to work around early on and as your project progresses always communicate any changes in the desired outcomes.

Make sure to embrace your consultants as an extension of your team. If you don’t, there will be disconnect between the teams and the relationship will not work out. Trust is also incredibly important. Consultants are highly skilled and should be able to handle projects you give to them. Also, contrary to popular belief, all consultants aren’t “yes men” and can have great suggestions for how to streamline projects or tweak certain aspects. Keep an open mind and consider what they have to say!

The process of hiring a consulting firm may seem daunting at first, but taking the time to know what to look for will streamline the process and help you recognize what is most important when building your team. Once you select a firm, trust and open communication between your company and your new team is key. Closely integrating the two teams and fostering mutual respect between them both will help you on your way to building strong, lasting relationships and successful projects.

About the Author/Theo Nissim

Theo Nissim, CEO at Gemini Solutions, Theo is a seasoned Silicon Valley technology executive with more than 20 years of experience. He has led pre-IPO start-ups, built dozens of technical teams, developed technology strategies and driven innovative products and solutions to market. One of Theo’s many strengths and passions is managing large scale, cross-functional development efforts to high profile product releases. Theo has held executive and management positions with large public companies, Sun Microsystems and Wind River Systems, and served as the Engineering Vice President for VC funded start-ups, Digital Fountain and AdKnowledge.

Theo has a Masters Degree in Computer Engineering from the Technion, Israeli Institute of Technology in Haifa Israel. He lives in Palo Alto, California, with his wife and twin boys

September 10, 2015
App Dev: Stop Spinning Wheels on the Spinning Wheel

When it comes to websites and apps – speed matters; today’s consumers want everything yesterday. Recent studies show that there is no surer way to lose the trust of a consumer than to produce an app with sluggish performance. Recently, Amazon reported that for every tenth of a second of latency, sales decrease by one percent. Furthermore, almost half (48 percent) of consumers stated that they immediately uninstalled an app after slow performance. That’s a huge cost that translates directly to the bottom line.

Today’s websites and applications are hyper competitive when it comes to user experience (UX). Consumers are educated – and if the digital experience isn’t engaging and effective, they will leave for a digital channel that does deliver that experience.

The problem lies in the collaboration between UX designers and line of business teams. UX designers load up their sites and apps with cool content and hot third party JavaScript for a strong visual appeal. Following that, teams who are looking at competitor’s digital properties ask for even more content to be added in hopes that the app will be even more useful. Unfortunately, with this strategy, the end result is an incredible experience that probably performs somewhere between “eh” and “terrible”. Off go the consumers because the one thing they hate worse than something boring? Something slow.

So, it’s tough being a designer; contrary to popular belief, the reality is that web loading speeds on average are actually getting slower on a global scale. As more users flock to social media, and ecommerce sites to get their fix of images, videos and interactive plugins, web speeds have been plummeting. Factor in that 50 million people in the U.S. now watch streaming video on mobile phones, and the issue become clear. High-speed Internet is no longer enough to get content to consumers in a timely manner. In fact, you have to assume high speed is irrelevant because so much interaction is now “over the air” mobile.

The question now becomes, what can designers, developers and organizations do to maximize experience and keep things fast in a world where performance is slowly degrading?

Testing is Mission Critical

It’s not rocket science that before a website or app is released into the wild, it needs to be tested and then deployed it in a way where it can be monitored to check it for performance issues, or any bugs that might annoy users into never looking at it again. The “it will get better” model of the past is dead. You have to get it right the first time.

However, testing and monitoring once isn’t enough; because there are so many variables that are introduced by 3^rd party content – from a paid ad slot to an image to logins for social accounts to all the various marketing tags. A failure on the part of any one of these sources can damage performance. Furthermore, those third party bits are part of long chains of infrastructure themselves– with lots of exposed weak points. If your third party social media login JavaScript object can’t communicate to its house – or the pipe it’s house uses to talk to Facebook is down, all the consumer knows is that they won’t be back.

As good of an idea as it may seem to drop in one more marketing or advertising capability to increase the revenue generated by applications, it needs to be tested and monitored first to make sure it doesn’t have the opposite effect. Without fully assessing the risks associated with the addition of these services, it’s hard to evaluate whether it will help or hurt the business.

Finally, be sure to load test at different traffic levels. It can be easy to focus testing on best-case scenarios, but be aware that once released, apps need to perform under a whole host of different network conditions.

Keep It Simple, but Don’t be Stupid

Design is always a balance between the desire to give consumers more functionality and a more interactive and friendly UI. For many organizations, this means coming up with something snazzy, and then having developers and operations make sense of it to enable performance. So – often to avoid potential points of contention – the bias drifts towards being safe and ensuring performance at minimal cost.

Ultimately, the best experience will equal more sales, more views, more consumers, and better ROI. It actually is rooted in economic fact – the experience can and will drive more revenue, but only by investing in support.

So, how do you maintain and stretch experience without blowing up performance? The key is being predictable by spending time on research, evaluating different options and constantly testing them to see what provides the right balance of experience and performance. Just because you have been using the same social media JavaScript object from a well-known source doesn’t mean you shouldn’t always be comparing it against other alternatives. And given that at least 30% of web pages come from third parties, this means there is a lot of continuous monitoring and research to do.

Scientific Method

Ultimately what we are doing here is taking the artist’s mindset of maximizing creativity, and applying the scientific method. Researching all those third party options and checking their performance – before presenting to the DevOps team – provides the ammunition to show that it’s possible to affordably deliver great performance and a great experience. Then, partnering with DevOps to constantly monitor third party content makes sure that at the first sign of degradation, backup providers are waiting in the wings to be deployed.

About the Author/Adam Thier

Adam Thier is the Executive Vice President of Engineering at Keynote Systems. He brings Keynote over 25 years of software development and product experience ranging from a number of successful startups through engineering leadership roles at industry leaders such as SAP. In particular, he is an expert in analytic applications, predictive analytics, massively parallel in-memory databases, and columnar store processing.

Prior to Keynote, Thier was the Senior Vice President of Frontline applications at SAP, and prior to that ran development for Hyperion’s applications portfolio prior to its acquisition by Oracle. Thier is an avid proponent and practitioner of design thinking and credits most of the success of the products he has been responsible for to deep engagement with customers and continuous co-innovation. Thier has a BA from Marist College.

September 1, 2015
ARA tools can help you move apps easily to the cloud

Chances are your organization has already moved some of its applications to the cloud. There, storage and computing capacity are provided as services, and everybody in your enterprise can access the apps and related data via the internet.

As we all know, the cloud enables organizations to scale up or down quickly according to their needs, while giving them tremendous flexibility in maintaining their computing environment. One advantage for using the cloud is that it helps reduce time-to-market and removes the need for upfront investments in infrastructure.

To help you simplify the process of moving apps, you should consider using an Application Release Automation (ARA) tool from a reputable vendor with experience in the cloud space.

Moving to the Cloud Involves Research and Difficult Decisions

The first decision is perhaps the hardest: determining which variant of the cloud is best for your apps and your organization. Private or public cloud? Factors you should consider are: data security, privacy, legal compliance, network latency, whether the organization has the in-house resources to create and maintain a private cloud, and which cloud flavor provides the best combination of flexibility, compliance and cost-effectiveness.

Then, you have to weigh up the pros and cons of using the different cloud flavors, principally these:

•       Software-as-a-Service (SaaS)

•       Platform-as-a-Service (PaaS)

•       Infrastructure-as-a-Service (IaaS)

After the big decisions come the technical issues of how you are going to move your applications. Moving apps can be very difficult as many apps are complex and tied closely to the infrastructure landscape where they are deployed. Moving to a new landscape, such as the cloud, can be fraught with risks and challenges.

What are ARA Tools?

ARA tools focus on the modeling and deployment of custom application software releases and their associated configurations, often for Java Platform, Enterprise Edition (Java EE) and .NET applications. These tools, according to Gartner, offer versioning to enable best practices in moving related artifacts, applications, configurations and data together across the application life cycle. ARA tools support continuous release deployment. They often include workflow engines to assist in automating and tracking human activities.

Core activities include:

•            Packaging — creating a collection of multiple configuration items that must be deployed at the same time

•            Dependency Mapping — modeling full application dependencies between components of the application

•            Software Deployment — using package contents to install applications and configure their operating environments

•            Promotion — delivery of tested packages to an environment of higher criticality

•            Compliance — documenting adherence to processes and validating deployed application configurations

At its simplest, an ARA tool helps developers to map application components and configurations to targets, such as binary code, connection configuration, database updates, queue definitions, and web service end-points. This helps to remove the coupling between the application and its host infrastructure.

First Step in Using an ARA Tool to Move Apps to the Cloud

Using a sophisticated ARA tool, you can install applications in a cloud environment automatically. Nearly all ARA tools will enable you to define the application in the tool, ideally specifying a package for each version of each application. Each package will contain all of the components to make an application run, as well as links to the environments where you want to deploy.

If you use a model-based ARA tool, you will be able to eliminate much of your ‘how’ issues as the tool will automate most of the steps involved.

Second Step

Next, you must decide whether you want to move an app all at once or piecemeal. To err on the side of caution, you would be better off taking baby steps so you can learn and document as you go. Ideally, you might start by just moving some specific aspects such as static web content and front-end web servers. A model-based ARA tool will help you move forward quite effortlessly, whether your targets are in an on-premise or cloud environment.

Interacting with your targets is easy, via SSH, WinRM, REST — in fact, you can choose pretty much any connection protocol. You won’t even need to define new workflows or steps for this, as the tool will take care of the changes and determine the new deployment plan. Of course, if you want to move the entire app to the cloud, ARA tools give you that option, too.

In general, ARA tools will enable you and your team to move apps to the cloud quickly and safely, with full audit trails.

Software deployment is often one of the sorest headache-inducing problems of moving operations to the cloud. However, if you use ARA tools, your problems should diminish if not disappear. Best of all: if you use a model-based ARA tool, you will be able to eliminate much of your ‘how’ issues as the tool will automate most of the steps involved.

About the Author/Tom Batchelor

Tom Batchelor is a sales engineer for XebiaLabs, a leading provider of automation software for DevOps and Continuous Delivery, helping companies to accelerate the delivery of new software.

August 26, 2015
Practice Safe SSH with Teleport

Decentralized Key Management and Sharing Is Not The Answer Practice Safe SSH with Teleport

View PostAll projects start off with the best intentions, user management and security around accounts won’t be an afterthought. Despite those intentions, the requirements to move fast tend to override things suchDecentralized Key Management and Sharing Is Not The Answer Practice Safe SSH with Teleport All projects start off with the best intentions, user management and security around accounts won’t be an afterthought. Despite those intentions, the requirements to move fast tend to override things such as account hygiene, and before you know it, you are trying to manage hundreds, if not thousands, of SSH keys and privileged accounts either manually or with a tool that wasn’t designed for key management. You also probably need to keep track of authorization privileges, and a shared document or spreadsheet is not the correct method, especially when you have systems that need to be PCI compliant or are in SOX scope.

Centralized Key Management

Does your current SSH key management strategy feel like this? Are you using manual methods to distribute and manage SSH public keys? As the number of hosts and users increase, this method becomes more and more unwieldy and also can present you with security and compliance risks. By moving to a centralized approach with Conjur’s Teleport open source solution, you are now able to benefit from the following: ● No more SSH key sharing between developers ● Each developer has their own unique login, with their own distinct set of privileges ● Simple SSH key creation and deletion

User Management

A proper strategy for programmatic provisioning and deprovisioning of user accounts is equally as important as SSH key management. In addition to SSH key management, Teleport also provides an LDAP service that allows for a customized list of users/groups that can be associated with specific projects and environments. When a new developer joins a project, you can quickly programmatically provision the account and access rights, and when a developer departs, you can revoke the rights as well as remove the SSH key.

SSH Key Rotation

Scheduled SSH Key rotation should also be part of the overall security strategy and posture, and for those systems that need to be PCI DSS compliant, SSH keys need to be rotated annually. By providing a centralized SSH key solution, Teleport allows you to seamlessly rotate the keys, as well as keep a detailed audit log around which key was rotated when.

Conclusion

SSH is a powerful tool that provides a great deal of value and security for your developers, but with that great power comes great responsibility. Teleport is a tool that allows you to provide that power to your developers while also knowing that you are practicing safe SSH and are being secure and responsible.as account hygiene, and before you know it, you are trying to manage hundreds, if not thousands, of SSH keys and privileged accounts either manually or with a tool that wasn’t designed for key management. You also probably need to keep track of authorization privileges, and a shared document or spreadsheet is not the correct method, especially when you have systems that need to be PCI compliant or are in SOX scope.

About the Author/Mike Kail

Mike Kail was Yahoo’s CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly scalable architectures, prior to joining Yahoo. Most recently, Kail served as VP of IT Operations at Netflix. Prior to that, he was VP of IT Operations at Attensity, where he was responsible for the Americas data center operations team; including managing various big data systems with their Hadoop cluster, HBase, and MongoDB components. He has been recognized widely for his insightful industry commentary on Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” He holds a B.S. in Computer Science from Iowa State University. Reach out to him on Twitter or LinkedIn.

August 24, 2015
Five things to understand about Enterprise DevOps Solutions
There is a lot of buzz in the industry around selling and consuming DevOps. Unfortunately there isn’t the same level of understanding or even a common definition about DevOps between consumers and service providers. In my experience the past couple of years of evangelizing DevOps, the following 5 aspects come to my mind as critical factors while considering and implementing enterprise DevOps solutions:
1. Evolving Architectural models
If you are a geek like me, and if you haven’t heard any of the following terms, you’ll probably google them immediately – Container technology, Microservices architecture, single page web apps (SPA), Node.js, mobile web apps, The Internet of things (Mobile awareness, sensors & wearables etc.), web APIs – these are the current trends in the application development space. Almost all of them disrupt traditional architectural models. And the reason I point this out is because they’ll also disrupt your traditional software development lifecycle (SDLC). The number of code & deployable units is only going in one direction, and that’s up. Very rapidly actually! That means source code management, build management, deployment & release management, dependency management, all become so much more relevant and cumbersome. The ONLY meaningful way to make these kinds of disruption manageable is through a mature DevOps approach, and a robust platform to enable DevOps. Developers always want to do the new and coolest thing. Enterprises will be well served to adopt a DevOps strategy NOW, before their own developers will cause so much disruption, that their IT strategy may fall flat.
1. Integration with existing security and governance models
More and more enterprises are headed towards a hybrid model of IT which involves traditional on-premise data centers, public cloud, private cloud and consumption of domain specific Software as a Service & Platform as a Service capabilities. Hybrid model also poses the same kinds of challenges discussed with some of the new architectural trends. How do you manage releases across so many disparate entities and providers? A centralized DevOps strategy can help mitigate issues posed in a hybrid model to a large extent. But the question is – what about the corporate policies around security and governance? Do we throw away existing tools & capabilities around change management, ticketing etc.? Disruption is a good thing for innovation, but too much disruption can also lead to disastrous outcomes. One of the key challenges that I’ve encountered while implementing an enterprise DevOps solution is to integrate the platform with existing security models and tools. Not all of them work together seamlessly all the time. But the key to success is to evaluate where the gaps are, and only bringing in new tools or capabilities where necessary, and not just for the sake of it (sell a solution, not a bunch of products).
1. DevOps enablement
One of my mentors in IBM used to say, that “a fool with a tool, is still a fool”. How true that is in the world of DevOps! Tooling is a key ingredient towards automation. In fact the concept of DevOps is not new at all, but the kinds of tools available today make automation possible in so many levels that was unthinkable a decade ago. But just providing a platform of seamlessly integrated tools for SDLC isn’t going to work. A level of “design thinking” is absolutely necessary towards DevOps enablement. A DevOps engineer should always be slotted in as a key member of this enablement team. Someone that can coach teams while starting new projects on – What elements of the tooling would apply for them? How to on-board the DevOps platform? What elements of automation are already available vs ones that’ll need to be newly created? What will be the roles and responsibilities of current team members in a DevOps world? – These are the elements that enterprises struggle with. Without a credible enablement program, a DevOps strategy is bound to be very slow in adoption, or just simply fail.
1. Transformation Investment
An enterprise DevOps platform and enablement program doesn’t come for free. I’ve constantly been challenged with questions like – what Line of business (LOB) is going to pay for it? Can’t we just use “open source” and make this all free? Can we only pay for what & when we use? All these are fair questions. And the debate about centralized IT expenditure vs LOB expenditure isn’t a new one, and will not go away either. But DevOps is disruptive enough and WILL challenge some of these old ideas and habits. “Automation as a Service” is certainly a viable option that can be availed on a consumption model. Open source tools are available by the dozen. And what comes for free with open source tools is just the usage license, and nothing else. You’ll still have to integrate them with your platform, still write automation scripts and manage them, and enterprise grade tools are usually not totally free and there is some cost involved in acquiring and managing them. All that being said, DevOps IS very much an investment. It is an investment for speed of delivery, higher quality of deliverables through automation and perhaps some cost take out in the form of reduced or re-assigned resources that were performing traditional activities in SDLC. There are several models to ascertain return on investment (ROI) on such investments, but I’ll refrain from getting into that discussion in this article. I’ll just leave this with the infamous cliché – there is no free lunch!
1. Top Down vs Bottoms up buy-in
Typically I’ve been involved in DevOps strategy conversations for enterprises at the executive levels, and they seem to be all over it. They love some of the cost take out numbers when they see it, deployment cycle time reduction and aggressive time to market fascinates them. And legitimately so. Getting executive level buy-in and support is absolutely key for any transformation to be successful, DevOps included. But just a top down approach isn’t going to make DevOps successful. It is imperative to reach out to developers and architects under each tower or LOB and get their buy-in as well. Developers and testers love their tools and methods, and are very unwilling to give them up if the strategy calls for standardization of tools (which, by the way has to happen to some degree to gain efficiencies). DevOps also redefines roles in development and testing teams through the level of automation it brings in. This causes a lot of grief amongst the staff, and as a service provider and enabler, I’m sometimes perceived as the ‘enemy’, which is never a good sign for a successful transformation. Developers and testers also have the domain knowledge around how builds are done today, what the application component dependencies are, what test scenarios are more relevant and so on and so forth, information that is so critical to understand for automation. Make friends with the developers and testers to be successful.

About the Author/ Sunil Joshi

Sunil is an Executive Architect with IBM. He is currently the Application Development & Innovation (AD&I) DevOps offering owner for Global Business Services. He is IBM Senior Certified and Open group certified Distinguished Architect. His specialization are in the areas of hybrid cloud solutions, platform as a service and DevOps strategy. He’s created complex hybrid solutions on cloud and DevOps for large enterprises. Sunil has authored several IBM Redbooks, blogs and also a co-author of the IBM Cloud Computing Reference Architecture (CCRA).

Sunil is passionate about international music, multi-cultural cuisine, active sports and mentoring school & college students on career path and technology.

Contact Sunil on
August 20, 2015
How to lower risk in agile development
The increasing complexity of application development and subsequent rise of Agile development is changing the risk appetite in many software development organizations. Unless you’ve got an application which is highly regulated or mission-critical, it’s rarely feasible or sensible to manage Quality Assurance within the zero-bug environment often associated to Waterfall. Software development teams can become handcuffed by the lack of flexibility and struggle to maintain a focus on delivering business value. Agile methodologies paired with DevOps emphasize speed, rapid iteration and a “fix as you go” mentality over driving toward a perfect product out of the gates. So how can we lower risk in agile development?

There are other contributing factors to the growth in software risk, notably the continuing adoption of cloud computing. Given the appealing economics and flexibility for updating and repairing code in the cloud, many teams will choose to host even the most high-risk data on the cloud. Conversely, teams must focus even more attention on security, as the cloud exposes more data outside of the company’s network.

Software interdependencies are another risk; many business processes today rely upon the use of outside services from APIs to OAuth authentication. Teams must be on top of changes in these external systems to ensure that critical functionality can still operate. This is especially true in a mobile context, where even the operating system and hardware components are changing at a rapid pace.

There doesn’t have to be a trade-off between speed and quality. It takes a change in mindset and processes, however: managing software risk in the age of Agile and cloud is a whole new game. Here are a few things to consider:
1. Balance risk with business needs: A shining reason behind Agile’s popularity is the unceasing demand for speed and business alignment. Software and IT organizations have realized that in order for their employers to be competitive, they must operate in ways that are highly business-responsive and adaptive. Agile also helps organizations address the complexity of software development today, given the impact of mobile devices, the proliferation of new languages and tools for Web apps, growth in cloud-based computing and the overall importance of digital processes to a company’s success. QA teams need a more educated and informed approach to testing. That means taking on a measured approach to risk, wherein risk management tasks are implemented with business priorities in mind rather than as a one-size-fits-all strategy.
1. Risk-based testing: In order to take on more risk as part of Agile and DevOps thinking, there must be proper checks and balances integrated within the testing process. Instead of testing every feature and function, and shifting timelines, prioritize testing and quality management measures to fit business priorities. Risk-based testing commonly assigns a risk rating score for individual tests, which gives developers and QA an idea of the level of risk involved in delivering the code covered by that test if the test is skipped. As a result, the product team might spend more time testing versions of the application for devices which comprise the most important or largest sector of the customer base. However, common device types and operating systems are not the only variables that can factor into risk scores. For example, if one particularly large customer relies on a key feature or function, that should mandate additional testing around that area of the application. By linking business drivers to development and testing, organizations can still deliver quickly yet with the assurance of superior results in the areas that matter most to revenues and customer satisfaction. Ongoing testing of high priority application features also results in the avoidance of costly, wholesale changes down the road.
1. Integrate development and testing: As mentioned earlier, integration between development and testing is critical for many projects, yet it is frequently overlooked when managing Agile teams. To maximize success, there needs to be a deeper understanding between coders and testers on potential ripple effects of introducing new features as they are planned. This can occur during the everyday processes of Agile collaboration and sprint planning. Testers should know early on which are the top risk areas affected by a piece of new development; testers and developers both should incorporate development best practices which focus on understanding and planning for interdependencies, such as designing code that limits the downstream impact of integrations.
1. Best of Breed tools: The market for tools has expanded vastly along with the onset of cloud, mobile, social and big data technologies and the DevOps and Agile movements. The average IT shop is using dozens of tools for application lifecycle management (ALM), build, automation, project management, change management and testing. The newer tools, designed for Agile and Web development, allow for rapid iteration yet still provide controls and collaboration features to minimize risk. Beyond functionality, look for tools that will integrate with your existing toolsets. This will allow for faster, real-time visibility on application deliverables, new features and any quality issues that have been discovered.
Software development is more complicated today than ever. The good news is, it’s much less expensive, faster and easier to make a change in the code compared with even a few years ago. Incorporating some risk into a product is good, because it means that innovation and time-to-market are top of mind. However, introducing too much risk in high-priority customer areas or critical periods in a company’s growth can sink a business. Understanding the difference is what can allow you to keep both your customers and executives happy, with a brisk yet manageable pace of innovation.

About the Author/Kevin Dunne

Kevin Dunne is the Director of Product Strategy at QASymphony, ensuring their continued commitment to innovation and delivering tools to create better software. With a deep interest in the emerging trends in software development and testing, Kevin is dedicated to collaborating with thought leaders in this space.

Kevin comes to QASymphony from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. As one of the first employees at QASymphony, Kevin has seen many facets of the business working in sales, customer support, marketing, and product management.

Kevin holds a Bachelor of Science degree from Vanderbilt University. Connect with Kevin on twitter.
August 20, 2015
How IT Operations Analytics is Delivering on the Promise of DevOps

DevOps is one of the most significant movements in IT of the past several years, and the same trends that are making DevOps so important – speed, automation, and iteration – are also opening up new opportunities for IT infrastructure management. DevOps, at heart, is a matter of adopting new philosophies of working as an IT team, while letting go of legacy processes and technologies that no longer deliver an adequate level of efficiency. DevOps is all about doing things in a more efficient, smart and cost-effective way by adopting the latest innovations, working across siloes to combine the strengths of different people on the team, and bringing different functions together to make a more responsive and effective DevOps organization.

In the same way, today’s IT operations analytics solutions are becoming more friendly to this spirit of collaboration, as infrastructure is becoming more complex and heterogeneous. DevOps teams have to work together in new ways, with different processes and different parts of the organization interacting in unique ways that might not have been expected just a few years ago. Similarly, today’s IT operations analytics world is evolving to run IT more smartly by taking advantage of new opportunities to manage the stack more efficiently.

Ultimately, the role of DevOps and the role of IT operations analytics are about developing competitive advantage. If your organization can use DevOps principles to build packages or release code faster or more accurately, you’re going to be ahead of the game compared to your competitors. If your organization can harness the power of the latest IT operations analytics innovations, you will similarly have a competitive edge because you will have a higher degree of control and visibility into what’s happening within your infrastructure. IT operations analytics can serve as an ideal complement to DevOps – because it helps to reinforce and protect the competitive advantage gains that are realized by DevOps.

Here’s what I mean by that statement: DevOps does a great job of combining speed, automation, and iteration. But as a practical issue, creating competitive advantage is more than new features, the apps you deliver must be reliable and high performance or customer expectations will not be met. IT operations analytics serves as a complement to the speed and agility of DevOps by identifying new innovation opportunities and providing “wow!” moments for the customer. With better IT operations analytics, you can exert better control over your IT infrastructure – and better control leads to bigger innovation opportunities, because you can keep the control in-house without having to rely on an outsourcer for identifying your innovation opportunities.

There are several market segments where the link between IT, the customer experience, and revenue are quite obvious. Optimizing online game play using real-time analytics is a great example, but the trend is much broader than that. With so much of the customer experience determined by IT systems, we are seeing more and more large customers moving to: (a) Continuous Integration and Continuous Delivery to accelerate delivery and (b) IT operations analytics as the way to ensure service delivery. IT operations analytics helps create the stable foundation for the high-speed and dynamic innovations of CI/CD.

With DevOps opening up an unprecedented level of speed, it’s important to have the right tools in place to process significant volumes of data. This is another area where IT operations analytics serves as an ideal complement to DevOps – because today’s IT operations analytics tools are powered by Big Data and machine learning, making it possible to achieve new levels of scalability. Unlike just a few years ago when getting a Big Data system up and running required significantly more resources, companies can get a lot more Big Data bang for the buck today than was possible even 3 years ago.

Now, companies are focusing on the analytic applications on top of Big Data, which is how businesses will find the optimization and innovation opportunities. Companies like Netflix are leading the charge in how Big Data can be used, not only to ensure service levels but also to create great customer experiences. While customer data may be the “crown jewel” of a corporation, IT operational data is the “diamond in the rough” that companies will be mining for the next big wins. We are just barely scratching the surface of what is possible with Big Data analytics of IT operational data – by drawing upon a fuller picture of what’s happening within the stack (various applications, servers, shared services, etc.), today’s IT operations analytics tools are going to help IT managers identify new insights and innovation opportunities that would not have been possible in the pre-DevOps era.

Another lesson of today’s reality of DevOps and IT operations analytics is that the divide that used to exist between customers and IT is almost gone. The future of IT is represented by the Internet of Things (IoT), where every system and behavior is monitored and analyzed in real-time, triggering operational processes from turning off a light to delighting a customer. Everyday objects, from household appliances to cars, are going to get exponentially “smarter,” and our IT processes need to evolve along with them to continually analyze, evaluate and respond to the ever-shifting ocean of data that is silently speaking to us. While DevOps and CI/CD define the trend to more rapid innovation, the collection and analysis of the reams of data generated by systems and customers will be the key to finding and maintaining competitive advantage.

This is where IT operations analytics will have an ever-more-important role as a complement to DevOps – with Big Data analytics and machine learning tools becoming more responsive and integrated into the life of overall IT operations, our IT admins are going to have more powerful insights at their fingertips each day. The convergence of IT operations analytics and DevOps will be a virtuous cycle of enhanced speed, smarter automation, and better control of IT operations for more reliable service and more delightful customer experiences.

About the Author/Omer Trajman

Omer Trajman, Co-Founder and CEO of Rocana. Omer’s fifteen years of front-line business and technical experience guide his vision for Rocana. Leading teams responsible for some of today’s largest modern database management system deployments, Omer has worked with customers and partners to identify where Big Data technology solutions address business needs. Omer’s experience in Big Data includes responsibilities as Vice President of Technology Solutions at Cloudera, focusing on Cloudera’s technology strategy and communication. Prior to this role, Omer served as Vice President of Customer Solutions at Cloudera, which included responsibility for Cloudera University, Cloudera’s Architectural Services and Cloudera’s Partner Engineering team. Before joining Cloudera, Omer was responsible for the Cloud Computing, Hadoop and Virtualization initiatives at Vertica. Omer received his Bachelor’s degree in Computer Engineering from Tufts University and was a visiting scholar at Oxford University reading in Computation and Electrical Engineering with a focus on large scale distributed systems.

August 19, 2015
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.

About The Author ⁄ Kevin Fishner

Kevin 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.

August 18, 2015
Webinar: Keeping your Remote Access Private with SSH keys

In this webinar we’ll discuss the basics of SSH authentication – passwords, keys, and MFA, oh my! We’ll also investigate some common patterns of key propagation — how do you get your users’ keys onto the appropriate machines — including:

* Manual distribution

* LDAP

* Puppet/Chef configuration

* Advanced techniques

We’ll also highlight the different challenges involved when doing this against different IaaS vendors (AWS and GCE), in a locally-hosted environment, and in the hybrid of the two.

Recorded: Tuesday, August 25th, 2015

Recording

Slides

[seoslides embed_id=”7b1b75b0ce7d” script_src=”https://devopsy.kinsta.cloud/embed-script/9294/9296/” overview_src=”https://devopsy.kinsta.cloud/slides/9294/” title=”” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” /]

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Topher Marie, CTO of JumpCloud

Topher is the CTO and Co-Founder of JumpCloud. Previously he spent five years at Symplified as its lead engineer holding a variety of titles including Architect and Development Manager. The bulk of his time was spent wrestling with the concepts and mechanisms of provable identity – SAML, IWA/Kerberos, PKI, OAuth, OpenID, and multi-factor authentication to name a few. Topher holds Bachelor and Master of Science degrees from the Colorado School of Mines in the area of Math with emphasis in Computer Science. He also spent several subsequent years at that university as a part-time professor for both computer science and pure math courses.

August 14, 2015
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.

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.

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

About the Author/Prathap Dendi

Prathap 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.
August 14, 2015