IBM has added an automated testing tool to the portfolio of DevOps tools it has developed for mainframes.
Sanjay Chandru, director of Z DevOps for IBM, said IBM Z Open Unit Test adds a continuous testing capability to the continuous integration/continuous development (CI/CD) platform based on an instance of an open source Git repository developed by Rocket Software that IBM launched last year. The automated unit testing tool automatically records and plays back test data for both batch-oriented applications written in COBOL or PL/I and CICS transaction processing applications.
Chandru said IBM Z Open Unit Test is unique in that it eliminates the need to employ traditional debugging tools. Developers can generate test cases for COBOL CICS programs, as well as “stub out” CICS to achieving environment independence from CICS runtime during test case execution. A stub is an object that holds predetermined data, which is provided in response to calls made during tests. That approach eliminates the need to have objects that answer with real data. That means Z Open Unit Test operates without adding the overhead of a debugging tool, said Chandru.
Any test case and the resulting program created then can be stored in any source code management (SCM) system.
IBM is making a concerted effort to make mainframe a natural deployment target for any DevOps team, said Chandru. It increasingly has become apparent that millennials in particular aren’t biased toward one platform or another, as long as each platform is equally accessible, he noted, adding that as organizations embrace best DevOps practices to modernize their application portfolio, IBM wants to make sure the mainframe remains relevant.
IBM launched the z14 mainframe in the fourth quarter of 2017. According to the company, 92 of the world’s 100 biggest banks use its mainframes, which handle most global credit card transactions alongside billions of ATM transactions and annual passenger flight bookings. While use of mainframes overall isn’t growing, the platform isn’t going away anytime soon.
IBM has also enhanced the cryptographic capabilities of the z14 to make it one of the most secure platforms available and continues to invest in an instance of Linux for the mainframe. That latter capability makes the mainframe a more natural target for applications being developed and deployed using DevOps processes, said Chandru.
Of course, the biggest challenge when it comes to DevOps and mainframes is not necessarily the technology. Most mainframe applications have been developed using waterfall processes for decades. Getting those teams to embrace DevOps processes represents a significant cultural hurdle for any IT organization.
At the same time, however, DevOps teams who ignore mainframes are not taking advantage of an existing platform investment that has performance and security capabilities that are still unmatched after more than five decades. The real challenge is finding a way for old mainframe dogs to learn some new DevOps tricks while exposing proverbial whippersnappers to the capabilities of the most powerful mainstream platform ever built.
A recent HBR survey shows there is work to be done to advance DevOps in organizations
A survey of 654 subscribers to the Harvard Business Review found that while 86 percent of respondents said it is important for their organizations to be able to build and deploy software quickly, only 10 percent said they are successful at it.
Conducted by Harvard Business Review Analytic Services on behalf of Google, the survey found nearly half (48 percent) of respondents said their organization always relies on DevOps methodologies when deploying software, while another 21 percent rely on DevOps selectively. An additional 8 percent said their organization plans to adopt DevOps practices.
Among those respondents employing DevOps practices, the top benefits cited were increased speed to market (70 percent), productivity (67 percent), customer relevance (67 percent), innovation (66 percent) and product/service quality (64 percent). Despite those benefits, however, most organizations still have a significant amount of work to do in terms of implementing best DevOps practices—the three biggest hurdles organizations face are organizational silos (50 percent), legacy technologies (49 percent) and resistance to change (46 percent).
Melody Meckfessel, vice president of engineering for Google Cloud Platform (GCP), said these issues are precisely why Google is sharing how it operates in the form of site reliability engineering (SRE) principles, which are a prescriptive set of guidelines for implementing best DevOps practices. Not every organization needs to implement those principles to the same level, but just about every organization can benefit from adopting a set of well-defined engineering principles, said Meckfessel.
The challenge many organizations face is the fact that most of the IT staff are not engineers by trade. Most IT staffs are made up of administrators who tend to have limited programming skills. But Meckfessel said even IT organizations that don’t necessarily have a lot of engineering expertise still can benefit from automating operations based on the SRE principles.
Many of those organizations will need to slow down the rate at which they are building applications today to be able to speed up tomorrow. It takes time for organizations to master the cultural change required to implement DevOps practices. But once they begin to master DevOps, the benefits to the organization compound quickly. Meckfessel said two of the most important attributes of DevOps is adopting an immersive approach to training and establishing a no-blame culture within the IT organization when it comes time to conduct post-mortems. That latter goal is especially difficult to achieve sometimes, because most interactions between developers and IT operations teams historically have been less than positive.
Meckfessel also noted it’s critical now for organizations to incorporate cybersecurity into its DevOps processes as well, which requires not only additional training for developers but also closer alignment with cybersecurity teams.
It’s now only a matter of time before the complexity associated with emerging technologies such as microservices based on containers force many organizations to dive deeper in DevOps. The real challenge now is charting a path of least resistance that also generates the maximum level of benefit for all concerned.
DevSecOps is changing our perspective toward security and is equipping us to deal with its challenges in an intelligible manner. The systematic approach of DevSecOps helps us add value to our business processes while ensuring security.
Here’s a summary of the key inputs and a recipe for a successful software development project. Implementing DevSecOps with the primary goal of enhancing security requires a step-by-step procedure.
It requires the unification of culturally disparate teams of Security, Operations, Development and Test for the sole purpose of building a product marked by quality and backed by security.
The DevSecOps process will require effective planning, design and release, which will be put together with a collaborative toolchain of technologies to bring about a common goal.
Furthermore, as organizations continue to rely on automated delivery, avenues are created for testing opportunities beyond traditional bugs. In-house experts will be able to identify potential loopholes, design errors and even code weak spots.
Being able to identify weak spots and flaws well in advance helps organizations maintain a competitive front in the market and trustworthiness before its target audience.
DevSecOps Implementation Process and Road Map
1) Planning: Planning is the first approach to any task at hand and the core focus of DevSecOps—security—begins from here. In the planning stage, DevSecOps professionals must go beyond creating feature-based descriptions. The focus should also be on security and performance, acceptance test criteria, application interface and functionality and threat-defense models.
Tech terminology: Acceptance Test Criteria is used by DevSecOps professionals to understand user preferences and behavior to a software application behavior.
2) Developing: Developers should approach DevSecOps with a “how to do it” approach, rather than a “what to do” approach. It is important for developers to bring together available resources for guidance, have reliable practices and a code review system in place for themselves and for others in the team to follow.
3) Building: Automated build tools can uplift the whole DevSecOps implementation process tremendously. These tools ensure test-driven development, standards for release artifact generation and utilize tools to ensure the design aspect is in alignment with the team’s coding and security standards through statistic code analysis.
They can also be used to identify vulnerable libraries being used in your application and replace them with new ones.
4) Testing: Automated testing in DevSecOps should utilize strong testing practices including front-end, back-end, API, database and passive security testing.
Tech Terminology: Passive Security Testing is a developmental stage testing where security testing is not conducted directly on the target.
5) Securing: Traditional testing methods always remain in place in DevSecOps exercise. However, somewhere down the line, there is a tendency to identify issues toward the end of the development process.
Through advanced practices such as security scanning, we tend to become more aware of the issues and can determine if the threat is a serious one or not.
6) Deploying: Automated provisioning and deployment can fast-track the development process while making it a more consistent one. Infrastructure-as-code tools can perform the aforementioned audit properties and configurations and ensure secure configurations across the IT infrastructure.
7) Operating: Regular monitoring and upgrades are the Operations team’s important tasks. DevSecOps teams ensure to deploy infrastructure-as-a-code tools to update and secure the entire organization’s infrastructure in a quick and efficient manner with no scope for human error. Operations personnel have to be especially watchful of zero-day vulnerabilities.
Tech Terminology: Zero-Day vulnerabilities are a software breach that remains unknown to software productions personnel and can eat away at a computer program and other components such as a network.
8) Monitoring: Constantly keeping a watch for irregularities in security can save an organization from a breach. Hence, it is essential to implement a strong continuous monitoring program with real-time to keep a track of system performance and identify any exploits in their early stages.
9) Scaling: Gone are the days when organizations spent precious hours and money on the maintenance of large data centers. With the introduction of virtualization solutions and the cloud, organizations can scale their IT infrastructure or replace it in the event of a threat, which would be impossible to do with a traditional data center.
10) Adapting: Continuous improvement is key to any organization’s growth. An organization will only be able to achieve the desired growth of it evolves in its practices including DevSecOps practices—security, functionality and performance. Therefore, an organization should adapt to continuous improvement and external changing trends.
The DevSecOps is in itself a process of innovation that substantially adds value to an organization.
Point to Remember: Security is everyone’s responsibility.
A testing center of excellence (TCoE) can help you leverage automated testing efforts.
The “World Quality Report 2018-19” claims that test automation is almost a heal-all concept in QA and one of the most booming trends for the near future. Still, the general percentage of automated testing in overall test efforts is quite modest. Apart from technical and financial impediments, test automation can be hampered by a number of organizational challenges. Here, testing centers of excellence (TCoEs) may be of practical value.
Let’s find out what TCoE is, why test automation is a must and how TCoE may come in handy on your way to higher test automation levels.
TCoE: Capsule Review
A TCoE provides QA optimization and control due to consolidated testing best practices, tools, standardized methodologies and testing metrics. It aims to centralize QA resources dispersed around the whole enterprise, thus being more relevant for large-scale organizations with a number of departments or even subsidiaries. Capgemini research results prove that TCoE can bring such tangible benefits as optimized QA resources (people, budgets and tools), reduced testing time (by 30 percent) and costs (by 35 percent in a three-year time frame) and increased test automation rate (up to 50 percent).
Why Level Up Test Automation
Test automation is not just hype, but a proven way to get more from your testing. The ever-growing popularity of Agile and DevOps/continuous delivery projects necessitates that testing be performed within a shorter time frame. Test automation tools are highly efficient in performing the most time-consuming types of testing and the ones comprising large amounts of data, such as regression, performance, data warehouse or load testing. With its ability to execute thousands of test cases during every run, test automation provides coverage unachievable with manual testing resources.
Test Automation Challenges That TCoE Can Solve
The promotion of test automation is acute as it can result in tangible benefits. For now, the average level of automated test activities is only around 16 percent, as reported by the leading CIOs from around the world. However, it is pointless to automate all testing activities. Test automation is not a panacea for every testing project or testing type. Each project’s automated testing efforts require a careful consideration and ROI assessment, as test automation has a number of limitations. For example, it can save the testing budget only in the long run. So, there’s no need to introduce automation for small-scale testing projects. Besides, even in projects with a large testing scope, test cases that are unique for each release or source code modification, rarely repeated test cases and those with difficult-to-measure or not purely objective output shouldn’t be automated.
However, the low rate of test automation comes not only from its natural technical impediments but also because of the organizational problems bound. Luckily, TCoE can handle some of test automation organizational challenges.
Test Strategy Lacking Test Automation
If the test strategy doesn’t fully correspond to software requirements and its peculiarities, it may lack testing types appropriate for automation. TCoE may be of help here as TCoE managers can assist test leads in building a more effective test strategy with respect to high-level QA priorities and help BAs to come up with multilevel software requirements, if a software requirements specification turns out to be incomplete.
Besides, the initial part of test automation requires a significant share of testing time (choosing the repeatable test cases and scenarios, scripting and maintaining them) and budget. Without TCoE, some test leads may try to economize and strike automated testing off the test strategy, sure that the moves will help them meet the rigid deadline and budget. If it’s truly impossible to implement relevant test automation and ensure acceptable testing quality stays within time and budget, TCoE managers can suggest revising the testing time and financial limits for the project.. The alternative, of course, often results in even more expenditures because of the release of heavily bugged software.
The Lack of Skilled Test Automation Engineers
QA teams consist mostly of manual test engineers without code writing skills needed to script and maintain automated test scenarios, while developers don’t have the knowledge of relevant automation testing tools or the experience in creating appropriate test cases. So, neither manual test engineers nor developers can fill the gap without sufficient training.
TCoE can help, with its managers knowing each test engineer and having an established knowledge-transfer process. TCoE managers can find test team members (preferably, manual test engineers) who are enthusiastic about test automation and provide training to them on a broadly applicable programming language (for example, Java or Python) and the most adjustable test automation tools (Selenium, Ranorex, TestComplete, etc.).
Silo Testing Processes
Uncoordinated and varied testing processes can hinder test automation. In different QA teams, test leads may choose disparate test management tools and test automation engineers are likely to use diverse test automation frameworks. Besides, with QA resources being dispersed around the company, it’s complicated to create a common base of automated scripts that can be reused in different testing projects.
Efficient test automation requires unified testing processes around the enterprise, which can be attained with TCoE. From the earliest stages of its maturity, TCoE focuses on aggregation, analysis and standardization of testing processes and test automation tools and frameworks. In addition, the TCoE team captures test patterns, creates modular automated test scripts and gathers them in a library to be fully or partially used through the same testing types or similar testing projects.
Excessive Test Automation Spend
Test automation may be pricey due to automation software license costs. Software license purchase for almost every testing project anew can turn test automation into a nightmare for the finance department and lead to excessive testing costs. TCoE handles this challenge by providing conventional licensed test automation software tools that can be used for a number of projects.
Also, test automation requires ongoing engineering resources for maintenance. Application under test (AUT) changes from iteration to iteration and all the automated scenarios should be checked for their validity. Only a few of them can remain unchanged while the majority needs restructuring and correction. A number of TCoE’s qualified test engineers ready to cater to continuous automated testing can be relocated to the project where they are most needed, not being bound to a distinct one. Besides, common test cases and scripts that were automated once can be reused through different projects.
Wrong Time for Test Automation
Another test automation pitfall is the difficulty of choosing the right time to introduce it during a development life cycle. If a test strategy implies a too-early start with scripting test cases, a test automation engineer risks finding the prepared test scripts and suites outdated in the next iteration due to requirements changes. At the same time, starting with test automation too late may result in excessive testing time and costs.
TCoE consolidates test automation best practices and QA professionals with the deep knowledge of software and its requirements. Thus, it’s much easier for TCoE managers than for each test lead separately to evaluate a certain project and decide when it’s the safest time to develop and implement automated tests.
On a Final Note
The relevance of test automation is here and is predicted to gradually grow in the future. Still, automated testing has a number of constraints and trying to reach higher levels of its implementation is bound to organizational challenges. TCoE can assist in solving such organizational test automation problems as an unbalanced test strategy, the lack of test automation engineers, uncoordinated testing processes, excessive test automation costs and inappropriate time for test automation.
The good news to start 2019 is that cloud adoption is growing rapidly. Most people realize this, but along with major growth comes some less welcome news. Wasted cloud spend is also up—often dramatically. Chances are, if you’re spending money on cloud, some of that money is being wasted. For some, a lot of that money is being wasted. Here are the numbers.
Predicted Cloud Spending 2019
The latest predictions from Gartner estimate that overall IT spending will reach $3.8 trillion this year, a growth of 3.2 percent over IT spending in 2018. Of this spend, public cloud spending is expected to reach $206.2 billion—of which, the fastest growing segment is infrastructure as a service (IaaS), which Gartner says will grow 27.6 percent in 2019 to reach $39.5 billion, up from $31 billion in 2018.
Now we can subdivide the public cloud spend number further to look just at compute resources—typically two-thirds of cloud spend is on compute, or about $26.3 billion. This segment of spend is especially vulnerable to waste, particularly from idle resources and oversized resources.
Wasted Cloud Spending from Idle Resources
Let’s first look at idle resources. This includes resources that are being paid for by the hour or minute, but that are not actually being used. Typically, this kind of waste occurs in non-production environments; that is, those used for development, testing, staging and QA. According to internal data available to my company, ParkMyCloud, about 44 percent of compute spend is on non-production resources.
Most non-production resources are only used during a 40-hour work week, and do not need to run 24/7. That means that for the other 128 hours of the week (76 percent), the resources sit idle, but are still paid for.
What does all this add up to?
$26.3 billion in compute spend x 0.44 non-production x 0.76 of week idle = $8.8 billion wasted on idle cloud resources.
Wasted Cloud Spending from Oversized Resources
The other source of wasted cloud spend is oversized infrastructure; that is, paying for resources at a larger capacity than needed.
RightScale found that 40 percent of instances were sized at least one size larger than needed for their workloads. Just by reducing an instance by one size, the cost is reduced by 50 percent. Downsizing by two sizes saves 75 percent.
The data we see in our users’ infrastructure confirms this, and in fact we find that it may even be a conservative estimate. Infrastructure managed in our platform has an average CPU utilization of 4.9 percent. Of course, this doesn’t take memory into account, and could be skewed by the fact that resources managed are more commonly used for non-production resources. However, it still paints a picture of gross underutilization, ripe for rightsizing and optimization.
If we take a conservative estimate of 40 percent of resources oversized by just one size, we find the following:
$26.3 billion in compute spend x 0.4 oversized x 0.5 overspend per oversized resource = $5.3 billion wasted on oversized resources.
Total Cloud Spending to be Wasted in 2019
So, between idle resources and overprovisioning, wasted cloud spend will exceed $14.1 billion in 2019. In fact, this estimation of wasted cloud spend is probably low. This calculation doesn’t even account for waste accumulated through orphaned resources, suboptimal pricing options, misuse of reserved instances and more.
Fortunately, cloud cost control is becoming top-of-mind as the industry is able to leverage cloud computing growth statistics to calculate the massive scale of this problem. If you are involved in your organization’s cloud infrastructure, why not make reducing cloud waste one of your 2019 objectives?
Cisco Systems this week launched an IoT Dev Center as part of an effort to foster development of a new generation of applications that will be deployed at the network edge.
Announced at the Cisco Live EMEA event, the IoT Dev Center provides access to sandboxes and tutorials for building highly distributed IoT applications that Cisco envisions will be deployed directly on top of Cisco routers and switches. To facilitate that effort, Cisco also launched a series of ruggedized switches and routers, which, in addition to usingCisco ASICs for processing network traffic, can be configured to include x86 processors that enable low-latency applications to be deployed at the edge.
The Cisco IoT Dev Center also provides access to a DevNet Ecosystem Exchange, through which organizations will be able to discover IoT applications optimized for Cisco infrastructure.
Susie Wee, senior vice president for the DevNet community at Cisco, said the IoT Dev Center is an extension of the company’s ongoing efforts to build a DevOps community around Cisco infrastructure. From Cisco’s perspective, IoT represents an instance of edge computing.
Cisco is attempting to extend its current dominance over networking infrastructure to include both networking gear for IoT environments and two-node hyperconverged infrastructure (HCI) platforms intended to be deployed at the network edge. Each of those systems will be connected via the Cisco Application-Centric Infrastructure (ACI) software-defined network (SDN), which Cisco says enables intent-based networking when infused with advanced analytics.
Cisco claims it already has 40,000 customers using some element of its portfolio to drive an IoT application. As that ecosystem continues to evolve, Wee said it’s apparent that both operational technology (OT) teams, which historically have been responsible for embedded systems, and enterprise IT teams will need to embrace best DevOps practices to deploy, manage and update IoT applications. While embedded systems deployed by OT teams were not frequently updated, IoT applications will take advantage of containers and other microservices-based technologies to add new functionality more frequently and, when required, update systems to remediate potential vulnerabilities. By the end of the decade, many of those applications will be connected via 5G wireless networks that will provide enough bandwidth to make continuously updating edge applications much more practical than it is today.
Less clear going forward is the degree to which networking teams will become part of a larger DevOps teams. As more applications get deployed on switches and routers at the edge, it’s obvious networking teams will play a critical role. The issue is to what degree. In many cases, networking teams will attempt to provide developers with access to a defined set of resources they can access via a self-service portal. But there are also likely to be instances when developers will want programmatic control over network resources that can be invoked via application programming interfaces (APIs).
Naturally, Cisco is not the only networking vendor with similar edge computing ambitions. But while most IoT initiatives remain relative nascent, the next major battle for control over the network edge is more likely be determined by the sophistication of the processes enabled as it is the core underlying infrastructure.
We are pleased to announce the 2018 DevOps Dozen honorees. When I launched the DevOps Dozen, I hoped they would grow to reflect and recognize the best of the best in the maturing DevOps space.
This year, there is no doubt in my mind that the winners are unsurpassed in the DevOps community. In fact, the whole process of nominations was open; from the the public making the selections of finalists; the judges and the criteria they used, it really does represent our best efforts.
Congratulations to each and every one of the winners in the 12 categories. It is quite an accomplishment to make it this far into the process. But congratulations not only to the honorees—all of the finalists should be proud to be part of such an impressive list.
Since the nomination process was opened, our team has gone through thousands of votes to pick out the finalists in each category. It was not an easy task, as we couldn’t automate (DevOps) it; we had to do it by hand. Also, many thanks to the judges for making the hard calls and thanks to everyone here at DevOps.com for helping out.
So, without further ado, here are the 2018 DevOps Dozen winners:
Best DevOps Open Source Project
Jenkins X is the winner of the Best DevOps Open Source Project for 2018. Jenkins X enables developers to take advantage of Kubernetes to develop cloud-native applications without having to learn the intricacies of Kubernetes. Developers can quickly establish CD best practices and cloud development by using the Jenkins X guided workflow that takes full advantage of GitOps, or environments managed as code. The power of GitOps allows developers to easily define, manage, deploy and scale environments with full history and traceability. Jenkins X leverages and packages many other open source projects of the Cloud Native Computing Foundation community around Kubernetes such as Knative, Helm, Prometheus and Vault, providing automatic integration with them and saving users the trouble of integrating all of these components themselves.
Learn more: https://jenkins-x.io/
Best DevOps Commercial Solution
JFrog Artifactory from JFrog is the winner of the Best DevOps Commercial Solution for 2018. JFrog Artifactory is the world’s only universal repository manager, with more than 5 million developers worldwide supporting development organizations across more than 4,500 global enterprises, and supporting all major packaging formats (more than 25), build tools and CI server. In 2018, JFrog Artifactory also won an Innovator award from IDC and the Firestarter award from 451 Research. Artifactory integrates with your existing ecosystem, supporting end-to-end binary management that overcomes the complexity of working with different software package management systems, and provides consistency to your CI/CD workflow. Artifactory is available in OSS and commercial versions, supporting hybrid development and deployment across the enterprise. Learn more: https://jfrog.com/artifactory/features/
Best DevOps Solution Provider Executive
The voting in this category actually resulted in a tie between two of the leading CEOs in the DevOps space. Sacha Labourey is the CEO and founder of CloudBees, the company powering the continuous economy by building the world’s first end-to-end system for automating software delivery. Sacha is also a member of the board of advisors and an investor at Codenvy (formerly eXo Platform), as well as a board member and investor at Wallix. He is praised as being a visionary with a strong understanding of technology and business. Sacha is experienced in open source, cloud computing, software development and more.
Shlomi Ben Haim is co-founder and CEO of JFrog. He brings more than 20 years of experience in building profitable, high-growth information technology companies. Shlomi is a recognized visionary in the DevOps space, having now guided a company from its inception with just three co-founders (along with Yoav Landman and Fred Simon) to a privately held, global DevOps company with a billion-dollar valuation. With the releases of JFrog Xray and the JFrog EnterprisePlus platform in the last two years, Shlomi continues to foresee market dynamics and push JFrog forward to deliver next-generation solutions.
Best DevOps Solution Provider
Electric Cloud was recognized for the third year in a row by Gartner as the leading solution in Application Release Orchestration, scoring highest in three out of three use cases in Gartner’s 2018 critical capabilities for application release orchestration. In Q4, 2018, Forrester ranked Electric Cloud as a leader in the newly released report, “The Forrester Wave™: Continuous Delivery and Release Automation (CDRA).” Additionally, ElectricFlow has been selected by EMA Research as a Top 3 enterprise software product in its new report, “EMA Top 3 Enterprise Decision Guide for Artificial Intelligence (AI) and Machine Learning (ML).” The report provides pragmatic guidance to enterprises on how to optimally benefit from AI and ML and continuously release better software. Electric Cloud is also the founding partner of DevOps Enterprise Summit USA.
Most Innovative DevOps Solution of the Year
CA Brightside is the winner of the Most Innovative DevOps Solution for 2018. CA Brightside is the first cross-enterprise DevOps solution designed to greatly improve the productivity and efficiency of development teams to control, script and develop for the mainframe like any other cloud platform. CA Brightside is also a foundational element of the Open Mainframe Project’s Zowe initiative, the first open source project for the mainframe which strives to attract a new generation of IT administrators to mainframe platforms and make it easier to include mainframes within the larger scope of an integrated set of DevOps processes that span multiple platforms. CA Brightside is designed to make it easy to integrate the mainframe into enterprise DevOps workflows by allowing development teams to control, script and build for the mainframe just like they would for any other cloud platform through the use of familiar open source tools such as Jenkins, Gradle and IntelliJ via a command line interface (CLI). Learn more: https://www.ca.com/us/products/ca-brightside.html
Best DevOps Evangelist
Chris O’Malley, Compuware’s president and CEO, is the Top DevOps Evangelist for 2018. Chris is a highly vocal, incredibly passionate evangelist for DevOps and, more specifically, Agile and DevOps on the mainframe. Having led the Agile transformation at Compuware, he speaks from the heart. No other executive in the industry comes close to exhibiting the energy Chris brings to every engagement, whether it’s a customer meeting or a LinkedIn update. Chris is unwavering in his commitment to make Compuware customers successful and believes DevOps on the mainframe plays a critical role in facilitating that success. Since late 2014, Chris has spearheaded an effort to educate the marketplace on the benefits of DevOps and Agile on the mainframe, as well as create a new generation of mainframe software that speeds this effort. Chris’ extensive media coverage and social outreach in 2018, included more than 25 articles, blogs, interviews, podcasts and conference presentations. Check out a few of his recent posts on ZDnet, Forbes, InformationWeek, eWeek, DevOps.com Chat, AgileCXO and DevOps Enterprise Summit, as well as more than a dozen LinkedIn posts in 2018.
Best DevOps Transformation
Capital One was the judges’ choice for Best DevOps Transformation for 2018. As one of the most well-known brands in America and among the top 10 largest banks in the nation based on deposits, Capital One offers a wide range of financial products and services to commercial clients, small businesses and individual consumers, both online and in-person at branch locations. The company was founded on the vision that the power of information, technology and testing could be harnessed to bring highly-customized financial products directly to consumers. The thousands of software engineers, testers and other professionals in the Capital One software development organization are making this vision a reality. Beyond their financial success and size, Capital One has a well-known and well-deserved reputation in the tech industry for being one of the most innovative and open source-friendly enterprises in the market.
George Swan is the winner of the Best DevOps Transformation Leader for 2018. George is director of Engineering Solutions at Autodesk, where his responsibilities include modernizing and optimizing Autodesk’s development and deployment capabilities using CI/CD solutions and best practices. George spearheaded the Engineering Solutions team tasked with modernizing the development and deployment solution based on CI/CD methodologies. The team built a source code solution using GitHub Enterprise and a binary management solution using Artifactory. Next, Autodesk standardized on CloudBees Core for orchestration and began implementing secure, automated Jenkins Pipelines. These pipelines enabled both continuous integration and more frequent deployments with shorter lead times via continuous delivery. Swan and his team delivered amazing results: “Productivity increased up to 10X. There is a team within Autodesk that saw a 10X improvement in productivity when they adopted CI/CD. If we can replicate even a fraction of this across the engineering organization, that will have an incredible impact.”
ShiftLeft Inc., winner of the Best New DevOps Solutions Company in 2018, is an innovator in application-specific cloud security, delivering the industry’s first fully automated security-as-a-service (SECaaS) solution that understands the unique security needs of each version of each application and creates custom security and threat detection for it. With ShiftLeft, DevOps can make threat detection part of their CI/CD process. ShiftLeft’s approach allows teams to both protect their applications immediately and enhance the security posture of their code. The company was founded by a team with extensive backgrounds in security and cloud infrastructure who were early innovators of technologies such as sandbox, next-generation firewall, next-generation electronic payment network and fraud modeling, as well as several open source initiatives. Headquartered in Santa Clara, Calif., ShiftLeft is backed by Bain Capital Ventures and Mayfield. For more information, see https://www.shiftleft.io/.
Best DevOps Book/eBook
“DevOps for the Modern Enterprise,” by Mirco Hering of Accenture, won the Best DevOps Book Award for 2018. In his book, Mirco, a thought leader in managing IT within legacy organizations, lays out a road map to success for IT managers, showing them how to create the right ecosystem, how to empower people to bring their best to work every day and how to put the right technology in the driver’s seat to propel their organization to success. But just having the right methods and tools will not magically transform an organization; the cultural change that is the most difficult is also the most impactful. Using principles from Agile, Lean and DevOps, as well as first-hand examples from the enterprise world, Mirco addresses the different challenges that legacy organizations face as they transform into modern IT departments. Mirco’s book is also featured by BookAuthority in the list of “26 Best New DevOps Books to Read in 2019.” View on Amazon.
Best DevOps Presentation of the Year
“Project to Product: Practical Realities at a Large Scale Enterprise,” a 30-minute presentation at DevOps Enterprise Summit London 2018, is the winner of the Best DevOps Presentation for 2018. The presentation featured Carmen DeArdo, currently working as senior VSM strategist at Tasktop, and Nicole Bryan, vice president of Product at Tasktop. Carmen DeArdo was the DevOps technology director at Nationwide Insurance, where he was part of the leadership team implementing DevOps practices and technologies across the 20+ IT areas at Nationwide. He is considered a DevOps industry leader, speaking at conferences and writing regularly on these topics at DevOps.com. He is also regularly interviewed by analysts (e.g. Forrester) and technical publications such as TechBeacon for research and articles. He has presented at previous DOES U.S. conferences. Check out Carmen’s Reflections from DevOps Enterprise Summit 2018 as well.
Nicole has more than 20 years of experience in software and product development, focused primarily on bringing data visualization/infographics and human factors considerations to the forefront of Agile and DevOps. She is passionate about increasing representation of women in technology and improving how software is created and delivered—making the experience enjoyable, fun and even delightful.
The panel of DOES18 speakers included Cornelia Davis, senior director of technology at Pivotal; Damon Edwards, co-founder and Chief Product Officer of Rundeck; Mik Kersten, CEO of Tasktop; Tom Limoncelli, SRE at StackOverflow.com; Gene Kim, founder of IT Revolution and co-author of “The DevOps Handbook,” “The Phoenix Project” and “Accelerate”; and Electric Cloud’s Sam Fell and Anders Wallgren.
Thanks to everyone who voted and nominated candidates. Stay tuned for 2019 DevOps Dozen and, as always, thanks for supporting DevOps.com and the rest of the MediaOps family of communities. If you have questions, please write us DD@devops.com.
Normalization of infrastructure through open source technologies is one way to make the move to the cloud an easier process for organizations.
For many modern companies, growth often means growing through acquisition. As organizations become larger, it often makes sense to acquire existing companies who are already creating the solutions they need than try to build them from scratch. However, this can often create a variety of conflicts and challenges—one of which is around infrastructure. For other companies that have grown more organically, it often can be difficult to modernize their legacy systems and bring their technology stack into the 21st century.
But cloud comes with big benefits: Some studies estimate a cloud-based infrastructure can reduce IT overhead costs by as much as 40 percent while also giving IT leaders a flexible way to scale up and down as needed. It also lends itself well for automation tasks, helping free valuable development time to add meaningful value to applications. And, the cloud isn’t just for tech startups. For example, a recent McKinsey & Company study noted that financial services companies have the highest percentage of server images deployed in private or public clouds, approaching nearly 100 percent (versus a median adoption rate of 19 percent). Cloud is certainly a hot topic, and for good reason.
In an ideal world, the IT landscape would be a greenfield, where every organization could start with a blank slate and build out their optimum infrastructure. But for most businesses, it is often more of a brownfield—muddied with old systems and stodgy practices—and it’s not always clear the best way to build on top of it. As more and more organizations look to a hybrid cloud approach as the infrastructure mode of the future, the need for a way to migrate legacy systems more easily is becoming an increasing necessity.
One of the ways to approach this is through the concept of normalization. This is a focus on utilizing industry-leading open source stack technologies that can create a hybrid cloud solution that is consistent and just works immediately: Kubernetes for containers, Fission for serverless functions and OpenStack for VMs, for example. As anyone in IT knows, this goal of normalization is nothing new, but achieving it can go a long way in helping your organization move into the cloud.
The reason behind this focus on providing a solution that leverages open source technology is the goal of creating this normalized structure that works across different cloud providers. This approach is because all the big three cloud providers have their own special services: Google has TPUs, Amazon has Lambda and Azure has Dynamics CRM. As you move data centers into the public cloud, you still have islands of infrastructure that are all built and run differently. How can DevOps truly have a consistent way of building and operating software in this sort of atmosphere? Open source technologies are a very powerful way to normalize that because they provide a solution that plugs into any infrastructure that you want.
One of the other keys to help bring your legacy systems into the cloud is to embrace change as it comes. While this is obviously a less technical recommendation than the above, it is still an important component to achieving success. It is no surprise that this sort of approach is one of the main tenets of the DevOps community that dates back to the beginning of the philosophy. It really started with the Puppets and Chefs of the world in the late 2000s and then continued with the rise of the OpenStack community. Finally, containers really started to form, from Vagrant and now to Kubernetes. Along this route, the IT industry has become much more sophisticated and there are a greater number of opportunities to achieve the normalization necessary to ease the transition to cloud—but only if you’re flexible and willing to adapt to change.
A related important distinction is to understand that complexity exists, and it’s not feasible to eliminate that complexity. Rather, you can take an approach of subdividing it and trying to contain and limit complexity. The strategy of normalization allows you to do this and keep complex parts of your infrastructure isolated as much as possible.
While there are many approaches to moving legacy systems into the cloud—from rehosting (a lift-and-shift approach) to refactoring (completely re-imagining how the application is architected and developed)—turning your current infrastructure into a cloud by leveraging existing and powerful open source tools is one of the most effective approaches that extract the most value for many organizations. This hybrid cloud approach gives organizations the ability to not only leverage cutting-edge cloud solutions that are agnostic to provider, but also provides a real way for companies to continue utilizing legacy systems that still provide meaningful value for their applications. This flexible, bespoke approach to hybrid cloud enables an entirely new approach to software infrastructure and opens many new doors for sustained success.
Here’s a full discussion on this topic with Alan Shimel, editor in chief of DevOps.com, posted on DevOpsTV:
New Security Flaws Creep into Reliable Old Systems
In cybersecurity, we are often like hunters. Our eyes are firmly glued to the horizon, scanning for the next breakout vulnerability (along with the right designing tools, techniques and tactics to stop it). However, this forward-looking focus can have the surprising effect of dampening our overall security awareness, blinding us to deep-seated dangers that exist all around, and which attackers are all too happy to exploit.
I often compare modern cybersecurity to a suit of Kevlar armor. The seemingly ethereal properties of Kevlar can block high-velocity rounds and all manner of modern, powerful weaponry. It may even make a wearer feel somewhat invincible. However, a comparatively ancient bow and arrow weapon system, first crafted sometime around 1000 B.C., can often penetrate that protection. A sharp knife, probably the second oldest weapon in the world behind rocks, can slice right though Kevlar as easily as if it were shredding a cotton sweatshirt. And then there’s the little matter of Kevlar not being able to protect every single millimeter of the human body. If an attacker can find any gap to deliver a damaging blow, they will—much like small, exploitable areas in software.
In cybersecurity, many organizations are similarly vulnerable to flaws on systems that are eight or 10 years old, which in modern computing terms just about qualifies them for a gold watch and a pension. But if you think flaws on these elderly systems are harmless, then you’ve probably got a blue screen of death or two in your future.
A Vulnerability for a Veteran
One of the oldest and most used JavaScript libraries is jQuery, an open source resource that helps with everything from event handling, to DOM tree traversal and manipulation, to generating animations. It’s quite a workhorse, and has been used for many years. People assume that because the library is so established at this point, that it must have been completely vetted, with any vulnerabilities removed.
Sadly, this is not the case. By default, most applications that rely on jQuery use the internal library’s instructions for authentication. For example, with Apache servers, this means checking the .htaccess files. Few developers designing programs that use Apache probably thought to check to make sure that Apache server updates included .htaccess. After all, why would Apache remove that critical component, which has been a bedrock of security for years?
As strange as it may seem, that is exactly what Apache did in version 2.3.9. Apparently, having to check the .htaccess configuration files every time a program needed to run was slowing things down too much. Removing it improved overall Apache performance, but also created a vulnerability that most people didn’t know about. If developers didn’t bother to check to see if their apps could still reach the .htaccess files, most requests would simply be accepted without scrutiny.
Recently, experts discovered that flaw and noted that using it would allow unauthorized users to upload and run shells or almost any type of code on supposedly secure systems. This led to the creation of a vulnerability alert designated CVE-2018-9206 in October. But, the ease at which the flaw was discovered by a security researcher implies that professional hackers, whose sole aim is to search for vulnerabilities such as this, probably already have discovered it. After all, despite the publicity, patches and fixes brought about in the aftermath, a similar high-impact attack happened just a few weeks later, in which Bitcoin-thieving malware was unleashed on a popular NPM lib downloaded by millions every week.
The Butler Did It
Like jQuery, Jenkins is an open source offering, and one of the most popular of its kind. With its helpful servant-like name, it makes sense that Jenkins is used as an automation server by development teams in many industries. When Jenkins is functioning correctly, it’s an extremely helpful tool. However, newly discovered flaws, and one recently uncovered crypto mining operation that is truly massive in scale, suggests that Jenkins was also doing a lot of work for the bad guys.
One of the most dangerous Jenkins vulnerabilities is called Java deserialization, which is designated as CVE-2017-1000353. It’s a complex attack, but one that has been around for a while. An attacker must submit two requests. The first one starts a bidirectional channel for downloading which is initially rejected by the server. However, the second request adds an upload channel which contains a payload with whatever commands the attacker wants, and utilizes the payload.jar script. Once the second request is sent, the communication is allowed on unpatched Jenkins servers.
Even on patched servers, exploits exist. For example, when running Jenkins in a Windows environment, by default it uses the NT AUTHORITYSYSTEM account to authorize users. This is dangerous because SYSTEM is granted full permissions on Windows servers. Developers can change the authority account, but often don’t. Their logic not to do so is based on the fact that Jenkins has been around forever, so people figure that any vulnerabilities have been patched a long time ago.
Most recently, a hacker used these aging Jenkins vulnerabilities to compromise several servers. The goal was adding a crypto miner program on every vulnerable Jenkins instance they could find. The miners took up valuable computing resources in their constant search for cryptocurrency. So far, they have found approximately 10,800 Monero crypto coins, with a value of almost $3.5 million.
What is Old is New Again
In both of these examples, vulnerabilities are being exploited by opportunistic attackers on platforms that many people consider to be safe. On the defensive side, the lack of security-aware development is allowing these hackers to breathe new life into old tricks. And despite a new round of success using aging vulnerabilities, many organizations have no plan in place to stop this vicious cycle.
Just because something is old does not mean that it’s harmless. And just because common libraries and resources have been around for years doesn’t mean that they are completely secure (for example, the No. 9 entry in the current OWASP top 10 is dedicated to dealing with Using Components With Known Vulnerabilities). Only through diligence and constant security training can we protect ourselves not only from dangerous threats creeping over the horizon, but also those which have already settled insidiously into our own backyards.
Moving to the cloud is becoming a must for many companies if they want to grow beyond their current footprint and be more innovative. But for many companies—especially those in the SMB space—their transition to the cloud is hindered by a lack of knowledge and experience, which often results in difficult migrations that sometimes just aren’t successful.
Since its inception, nClouds has helped organizations of all sizes move to the cloud successfully. Its experience as an AWS Premier consulting partner and its well-architected approach to cloud migration helps companies get the most from their infrastructure by engaging with the cloud, whether they’re adopting a hybrid environment or going all in on cloud.
In this DevOps Chat, JT Giri, nClouds founder and CEO, and I speak about the triggers that push companies to adopt cloud, some issues companies face in their decision-making and infrastructure’s role in an increasingly cloud-based IT world.
As usual, the video is immediately below, followed by the transcript of our conversation.
Transcript
Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat, or in this case, perhaps, watching a DevOps video. Happy to be joined here by my friend J.T. Giri, who is the CEO and founder of nClouds. J.T., welcome.
J.T. Giri: Hey—good morning, Alan. Thanks for having me.
Shimel: My pleasure, nice to have you here. J.T., let’s first of all say Merry Christmas, happy new year.
Giri: Thank you, and you.
Shimel: Yeah, it’s been an exciting—we were talking off camera, off mic—it’s been an exciting quarter for you. You’re a new time dad and moving homes and at the same time, nClouds’ business seems to be just booming along with everything else associated with Amazon Web Services and the cloud. So, congratulations.
Giri: Thank you. Exciting times.
Shimel: Yeah, it is. So, J.T., I wanted to talk a little bit about—you know, there’s people listening to this or watching this who are saying, “You know, I wanna be like Google,” or, “I wanna be Facebook” or, “I wanna be one of these unicorns in that I wanna harness the cloud. You know, we have our servers in a closet here or a data center or a third-party data center, but we’re not really cloud. And everything seems to be in the cloud. We wanna move to the cloud, but you know, we’re only maybe 250, 500 employees. How do we do that, right? Do we need a helper, like an nClouds. Do we need to update everything? Do we throw out the baby with the bath water and start new?”
I want you to tell us a little bit, sort of, what’s the typical sort of customer journeys that you see when you guys engage?
Giri: Yeah, absolutely. So, Alan, you know, we’ve talked in the past. I’ve been migrating companies to AWS ever since EC2 was in beta. And, as I would migrate these companies, people would realize that they need someone to manage it, right? So, that’s how, sort of, nClouds came to be. And as you mentioned, this has been an incredible year for us. We doubled the size and revenue and the number of people.
What we were seeing in an SMB type of market, when companies migrate or when they try to migrate to AWS, they still need to follow—obviously, they need to follow best practices because cloud or AWS is constantly changing, and the skill set is just not there. So, that’s where we come in play. We can make sure that your infrastructure is well-architected. We take an approach of migrating in a way where you’re really taking advantage of the cloud—so, for example, using containers, things that are really gonna help you to harness the power of cloud. And then, for most of our customers, you know, we’re providing 24/7 support. And when we see people try to do this themselves, they get a bad taste of cloud. They’re like, “Oh, this is not for us. We’re not really innovating fast.”
So, that’s why, Alan, we’ve been very successful, because there is a huge gap in SMB type of companies. There is a skill gap and just experience. We bring that to the table, and it’s been incredible. We’re able to add a lot of value.
Shimel: Sure. So, J.T., early on there, you said something about when an organization needs someone to help them manage their cloud migration—when does an organization recognize that they need someone to help them? What’s sort of a trigger point? You know, as, again, we spoke off camera a little bit—is it when someone dives in the pool and says, “Oh, my God, I can’t swim, it’s too deep?” Or is it, before you dive in the pool, a prudent person hires a swim coach, you know what I mean?
What are sort of the trigger things that people should see as a red flag or as a trigger event that says, “Hey, man, I should be getting some help, here”?
Giri: Yeah, that’s a great question. So, basically, it depends when the companies come to that realization that we need some outside help, right? Sometimes, it is that they will try to do the project themselves, or in other cases, they realize that they really want to just focus on delivering value to their customer, right? They really wanna just innovate fast.
So—and they see how they can just stay focused on that, and that’s something we do incredibly well. We have a build—we build systems and processes together where our key focus is to make sure the customer can deliver value to their customers fast and we want to make sure the infrastructure is not getting in their way.
So, you know, it’s just, this is becoming more and more popular, like, DevOps as a service, where companies are reaching out to partners like nClouds to help them with DevOps related tasks, like, with the migration, setting up CI/CD pipeline, becoming an extension to their team, so they can focus on their core business, right? And, you know, it really depends when they—sometimes, they come to that realization pretty fast, or sometimes they try to do things themselves, and when things don’t work out, they try to use someone like nClouds.
Shimel: So, J.T., generally, one of the hardest things in life is learning when to ask for help.
Giri: Right.
Shimel: And that includes cloud migrations and everything else. At the SMB level, mid-enterprise level, you don’t have an elaborate or as big a structure as, let’s say, you do with a large enterprise where you have layers and layers of management and hierarchy—a lot of the organizations you deal with are rather flat in their management structure.
So, who is it in the organization who finally kinda raises his hand and says, “Wait a second, I think we should engage in some professional help, right? I think we should being in some experts to help us.” Is it the CEO, CIO, someone lower than that? What’s your experience?
Shimel: Yes, normally, CTO, VP of Engineering type of person. And also, you know, as you know, we became a premier partner with AWS last year. So, AWS is—Amazon, it’s no secret that they’re very customer obsessed. So, they will—Amazon, when they’re speaking to a customer and if they see the customer is struggling, they will introduce someone like nClouds to help them out with the migration or just modernize their infrastructure. And sometimes, you know—actually, many times, they can come in with funding where they will offset some of the costs.
So, for a customer, it’s just like a no-brainer to see if we can have some external experts come in and fix up the infrastructure or streamline the infrastructure. So, you know, the conversation, normally, we do get a lot of business directly from people reaching out, like, “Hey, we need DevOps help,” but we also get a lot of business directly from AWS where they identify this customer needs help, and we get involved that way.
Shimel: So, I’m just gonna bring up two questions. The first one is on track with what we’re talking about. So, now the CTO or CIO or an executive says, “Yeah, we’re gonna bring in nClouds,” whether AWS referred it or is partially subsidizing it or what have you, but, “We’re gonna bring in nClouds or some other type of help”—is there any sort of pushback or resistance normally with, you know, when you’re dealing with people? The—not first responders, but the individual contributors who feel like, “Hey, man, I don’t wanna be replaced. I don’t wanna be outsourced. I don’t want to give up my cheese to some outside company who’s helping us” or, if so, how do you overcome that? How do you work with an organization like that?
Giri: Yeah, so, normally, there’s not a pushback, Alan. So, I was actually re-reading “The Venus Project” yesterday, and I was just reading the story of Brent, right?
Shimel: Mm-hmm.
Giri: So, when you’re talking to these customers, some of these guys are on their honeymoon with their pager with them, right? And then, when you’re coming in and you’re saying, “Hey, we’re gonna help you out with 24/7 support so you can get your life back” or, you know, “We’re gonna help you to streamline this DevOps work which you never really got the opportunity or time to work on, we’re gonna help you out with that,” right? And it’s incredible.
Sometimes, maybe the initial impression might be the same as you describe, like, “Hey, are you gonna take my job?” But as they understand the value, they normally are super happy. And another thing we do, Alan, in most of our engagements, we do this assessment called architected assessment where we’re coming in and we’re just reviewing your infrastructure to see how well you’re architected, and after that assessment, we give you, like, a roadmap, like, what are some things you should focus on the first month, and what are some things you should focus on short term and long term? And the assessment goes over cost, security, reliability, performance, and operation excellence.
So, you know, we can get, in the short-term road map, we can show some quick wins where the customer sees the value and they also get confident in our ability, so that’s sort of the path that works really well for us right now.
Shimel: Got it. J.T., another thing you mentioned is that nClouds is a premier Amazon partner. And, you know, in today’s world, we throw out platinum and gold and these sort of levels all the time—but really, within the Amazon hierarchy, a premier partner has sort of, they don’t hand that out like candy. Talk to us a little bit about what’s entailed in being an Amazon premier partner.
Giri: Yes. It’s a top tier status with AWS and in order to get there, like you said, there is only 25 premier partners in North America, and you have to show case studies, you have to show the training path of your employees, and you also have to have multiple competencies, like, we have DevOps competency, we have migration competency, and we’re also the well-architected partner.
And it’s just very subjective. You know, if you work closely with Amazon, even if you hit all the check boxes, they want to make sure that quality is there for premier partners. So, they look how you work well with your customer, what does your customer experience looks like, because that’s what Amazon cares about that as well.
So, you know, it’s just very hard to get to this status, and we’re honored to be at this level right now. This is great.
Shimel: Yep. So, J.T., let me go next kind of where I want to take this, and that’s—you know, two or three years ago, migrating a company onto an AWS, or it doesn’t have to be AWS, migrating a company onto the cloud, you know, you set up some virtual instances, maybe they had some separate storage, stuff like that, EC2 kinda stuff. But, you know, I just got back from Seattle a couple weeks ago from KubeCon and CloudNativeCon—Reinvent was the week before that. And certainly, Kubernetes and containers are kind of really quickly, quickly, quickly changing the landscape, here.
You know, are you seeing that as well? And what does that mean for—typically, SMB businesses are not leading edge or bleeding edge, right in [Cross talk] option?
Giri: Yeah.
Shimel: What are you guys seeing?
Giri: Yeah. You know, it’s very interesting. Who would’ve thought that the infrastructure we built a couple years ago would be considered a legacy infrastructure, you know? People using EC2 instances and an auto scaling group in Amazon’s world will kinda be called outdated right now.
So, we’re seeing incredible push and a lot of sort of initiatives on our customer side where they wanna go containers, pretty much like 90 percent of our engagements are around containers. Because it’s a no brainer, right? It makes the CI/CD pipeline much easier. You know, most of the time, containers are automatically integrated with scaling, so you can really binpack your resources, it has impact on your cost. So, you know, this is just—it just makes the infrastructure far more streamlined and far more easier to manage.
And as I mentioned, Alan, I’ve been migrating companies to Amazon and EC2 from the last 10 years, and I’ve been managing infrastructure as long as I’ve been migrating. So, it’s just, when I’m building infrastructure right now, it’s a no-brainer to build something using Kubernetes or on AWS we use EKS or—you know, depending on what the customer wants to do, and we had a customer the other day where they were saying, “I just wanna focus on delivering product to our customers, so what is the easiest way?” We use Fargate for them. Depending on the customer requirement, we’ll go Kubernetes, but long story short, it just makes a lot of sense these days to build infrastructure on containers, because they really streamline how you manage it in the long run. It just makes life easier.
Shimel: And that’s even at the SMB level?
Giri: Oh, absolutely, yeah. I mean, because the needs are the same. You need CI/CD pipeline, you need a way for you to scale infrastructure, you need a way for you to run batch or cron job type of jobs. And when you go with something like containers, you get there—like, you know, you don’t have to build home grown tools to facilitate these things. You know, containers or EKS or Kubernetes, they allow versioning when you’re deployed or auto scaling is sort of built in, you know, you can schedule batch jobs.
Just, it’s a no-brainer, you know? If you’re building out infrastructure, you should definitely explore containers each time, and that’s what we try to do every time. And it’s just incredible, the amount of success we’ve had before and after.
Shimel: Sure. So, as we sit here at the dawn of a new year, if I would’ve asked you in early 2018, do you think Kubernetes and containers would be one of the major stories of the year, I don’t know if you would’ve said yes or no. But as we sit here in the dawn of 2019 and we project ahead—let’s say I interview you and everything’s all well and at the end of next year, the end of this coming year, 2019, we sit down and talk about, “Well, what’s 2019 really show?”—what do you think are the big stories this year, J.T.? What do you think, coming down the pike, especially—I’m not talking about the world view. For nClouds and for your customer base, what do you think is really big for you in the coming year?
Giri: Yeah, so, I think in general, the application modernization will continue. We continue to see that trend, and this is also going to be big in SMB. So, we will continue to double down on AWS. It’s been an amazing partner. Our core values, our partnership is based on shared goals, so we’ll continue to kinda double down on that relationship.
And we’ll continue to utilize this well-architected framework. It helps us to assess the customers when we’re onboarding and it helps us to manage the customer, like, every time the customers were managing, we continued to run a well-architected assessment to make sure they’re well-architected, and they continue to stay well-architected.
And, yeah, I mean, just continue to focus on SMB, AWS, continue to align with well-architected framework. We also just spun off another company, it’s called nOps, and basically, it just helps to make sure the customers are well aligned with well architected framework, and it’s available on AWS Marketplace. So, we’ll continue to invest in that, because that solution has been incredible, nOps. A lot of our customers are seeing value in that, so, we are actually working with Amazon to give that solution to other partners like nClouds who can use it to manage their infrastructure to make sure the infrastructure is well architected, and we are also offering it to end customers who can use that tool to assess their infrastructure and continuously stay in compliance with well-architected framework.
Shimel: Excellent. You know, nOps, that’s something we’ll have to discuss on our next chat, J.T.
Giri: Yeah, absolutely.
Shimel: Well, you know what? We’ve been on almost a half hour here, so, unfortunately we’re about out of time for this one. J.T. Giri, CEO and founder of nClouds, thanks for being our guest on DevOps Chat.
Giri: Thank you so much for having me.
Shimel: My pleasure. Best of luck to nClouds this year, best of luck to you personally with your family and everything else, you know, it’s gonna be a busy year for you, my friend.
Giri: Absolutely. Thank you. Thank you.
Shimel: Alright. Hey, J.T. Giri, nClouds—you’re here with Alan Shimel on DevOps Chat. You’ve just listened to another chat. Bye bye, everyone.