devopsy.kinsta.cloud

Category: Features

  • DevOps Chats: Easing WFH with strongDM

    DevOps Chats: Easing WFH with strongDM

    strongDM wasn’t founded to help with remote workers forced out of the office by COVID-19. They have been around for five years now. But, the company does excel at allowing you to manage and audit remote access to all of your assets including DBs, servers and clusters (as well as apps and services) anywhere from anywhere.

    In this DevOps Chat we speak with strongDM Justin McCarthy, CTO and co-founder about how the company’s technology works and how it is helping companies move to remote access given current conditions.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel, and you’re listening to another DevOps Chat.

    Really happy to be joined on this chat by Justin McCarthy of strongDM. Hey, Justin, welcome to DevOps Chat.

    Justin McCarthy: Hey, Alan — thanks.

    Shimel: Pleasure to have you on here, Justin. You know, as we were talking a little bit off mic, I don’t know if we’ve introduced our MediaOps community, meaning DevOps and Security Boulevard and Container Journal, we haven’t introduced strongDM to them before. So, why don’t we start with that, Justin, and if you wouldn’t mind, in telling the story, talk about a little bit about your own personal journey.

    McCarthy: Yeah, sure thing. Alright, so, first, I guess I’ll just briefly introduce myself. So, I’m the co-founder and CTO of strongDM. And the product is actually, strongDM itself is the best way to manage and audit remote access to your servers and databases and really even Kubernetes clusters. So, that’s what we focus on. We are a remote access product.

    And the way we came to it is basically just a sort of typical startup story. We’ve been around for five years now, and at the beginning, it was scratching an itch just like so many other infrastructure and DevOps products out there. So, in my career, I’d always been involved in growing the teams that built the product and, inevitably, when you build a product and when you ship and when you have production data, you need to grant access to it. To analyze it, you need to grant access to it to administer it, to debug it.

    And that process always felt a little bit somewhere between inconvenient and scary, right? [Laughter] And so, basically, strongDM — yeah, is the response to all those feelings of, that it wasn’t quite as smooth as it could be, it wasn’t quite as safe as it could be.

    Shimel: Excellent, excellent. And you mentioned the company’s around now about five years.

    McCarthy: Mm-hmm.

    Shimel: That’s cool. Alright, let’s talk about — and you’re right, a lot of companies do grow out of one particular scratch to itch, and I’ve done my share of startups over the last 25 years. And what generally happens is, you find out that that particular itch may have associated itches, right, and there’s ancillary things — well, once I scratch that itch, the next itch pops up, right? To paraphrase “The Phoenix Project” or something and bottlenecks and the goal.

    Talk to us—what’s the itch, and then what have you guys found over the five years about kinda getting to that itch and associated itches?

    McCarthy: Yeah, yeah, definitely. So, at the core, the technical approach that it probably takes is that we are an identity-ware proxy, okay? And the first application of that was for database access. So, that’s where we started, right?

    Shimel: Mm-hmm.

    McCarthy: And in fact, at the beginning of time, we thought maybe that was all there was to it. But as we —

    Shimel: Hold on a second, though.

    McCarthy: Yeah, sure.

    Shimel: So, an identity-ware proxy, primarily for databases. For some of our audiences — our security … actually, our DevOps audience probably gets that, some of our security folks do. But break it down for me, Justin — what exactly do you mean by that?

    McCarthy: Sure thing. So, this is an architecture that I think a lot of folks might know as Zero Trust, a lot of folks might know as BeyondCorp, and there were a lot of examples of it out there in sort of an HTTP only case. When we originally conceived of and built the product, it was kind of even prior to a lot of that nomenclature existing.

    So, what an identity-ware proxy is, it is a proxy for a given type of service. Let’s continue to use databases as the example. So, if somebody needs to interact with a Postgres database or a Microsoft SQL Server database — so, let’s say Alan needs to connect your local copy of Tableau to one of those systems, right? So, Alan would log into strongDM and then strongDM would then conduct all of the traffic, essentially, forward it to the target systems. And the identity-ware aspect is that, essentially, we know it’s Alan the whole time and we’re proxying that traffic and we’re handling, essentially, all of the routing of that traffic.

    Shimel: Got it.

    McCarthy: And what’s interesting about that is that you kind of get a lot of the sort of — you get a separation of sort of Alan’s identity from, you know, the credentialing of the underlying system. So, you can actually credential that separately, which means you can rotate the underlying credentials without bothering Alan.

    Shimel: Now, in and of itself, can that be a security kinda setting up kinda almost a man in the middle type of situation?

    McCarthy: Yeah, so, in a lot of enterprises and environments, you at some point, you have to answer the question, how are we gonna audit this particular traffic stream, right? And so, there are also a lot of products out there that are dedicated to, for example, breaking TLS, right? Being the official man in the middle, right?

    Shimel: Yep.

    McCarthy: So, our product has an element of that built in, although it’s not a generic TLS breaker. What it is, is it’s a protocol specific way to answer the question, you know, given MySQL database selection, what would you want to know about what Alan did yesterday? And so, our product is focused on extracting that kind of rich information about what Alan did yesterday with respect to this MySQL connection.

    Shimel: Sure — great, great. Now, what made databases sort of, you know, the prime example of where to use this or as the first use case?

    McCarthy: Yeah, it was the first use case, largely because, again, we were scratching our own itch. [Laughter] So, that was the one that I most often encountered.

    Shimel: Okay.

    McCarthy: You know, and the appeal is, it’s phrased as, you know, “Can I please have access to this because I need to debug X?” Right? And that always, whoever is saying yes or maybe or no to that request, you know, there’s a lot of hope and trust that when you say yes it’s gonna be okay. So, what our product does is, it takes all that, the sort of emotions around that event [Laughter] and tries to give you an answer for how you make that convenient and how you make that safe for everyone.

    Shimel: Excellent, man — good. Alright. So, first ditch is the database and we figure that out and go from there, Justin.

    McCarthy: Sure. So, as I’m sure, as you found with many products, you know, why adopt 10 different products when you can get your existing vendor to do one more thing for you and then maybe reduce and concentrate more of your attention on one tool and so, that’s where our customers pushed us. And so, the next very strong demand that we saw was, now that all of our data systems are granted and revoked access through strongDM, could you also begin to do some of the interactive session and shell-based protocols? So, the first two there were obviously SSH and Windows Remote Desktop. So, that’s where we went next.

    And the theme, if you can sort of imagine it is, you know, everyone in my organization that maybe has engineer in their title or even analyst or scientist — essentially, all of those folks, they need more than just webpages to do their job, right?

    Shimel: They do.

    McCarthy: And so, if it were just webpages, then existing single sign-on would work great, right? But since it’s more than that, it’s deeper than that, it’s really that whole collection of use cases that our customers began asking us to take on.

    Shimel: Excellent. Good stuff. And so, let’s talk a little bit about — so, how, is this sort of distributed as a SaaS kind of thing or a web-based kinda interface? How does that work?

    McCarthy: Sure, yeah. I would say we are neither traditional SaaS, nor traditional on prem. So, in terms of how the product deploys, our customers end up running a bunch of it, but not all of it. So, with any system that involves credentials, any system that involves cryptography, operating it successfully and carefully is actually a huge part of getting it right, okay?

    Shimel: Mm-hmm.

    McCarthy: So, what we’ve tried to do is, we’ve tried to unify the sort of operation configuration. So, if you think of it like centralizing the policies, centralizing the key management.

    Shimel: Yeah.

    McCarthy: So, that’s the part that we host. But the part that actually runs the proxies and therefore essentially the actual conduits for all the data, that runs entirely in customer environments.

    Shimel: And what kind of environment are you talking about?

    McCarthy: Yeah, so, I would say our average customer, the answer is, like, several. [Laughter] So, there are very few environments where you have just one cloud, where you have just one prem data center. So, it ends up actually being several. And so, that’s another strength of our architecture and our approach is that our product, from day zero, was designed with that in mind, so you can run our proxies in Azure and in AWS and in your existing legacy data center. They all unify into one sort of access plane, and it doesn’t matter the product. The same grant access gesture applies to all of those environments.

    Shimel: Oh, okay. Very cool. Very cool. And, you know, from what you’re describing, to me, it doesn’t really make a difference whether I’m a cloud native company, let’s call it, right, or maybe an old line company that had my database running in the closet, right? This kind of identity by proxy is still something I can utilize to make my life easier.

    McCarthy: Yeah, absolutely. And of course, we would hope that it’s especially suited to a hybrid environment like that, because the ability to, from an end user point of view, from one of your data scientists, they just know the three logical things they need to access to do their job. They definitely don’t care what cloud it’s hosted in. They don’t care what data center it’s hosted in, but from the point of view of that end user, it just looks like one thing.

    Shimel: Okay. Now, let’s look at it from the lens of COVID, which we kinda always have to look at everything today through this lens — it seems like this would be a help, right, if I just had to move my whole workforce home, you know, remote. What have you guys been seeing on that?

    McCarthy: Yeah, I think our story there is pretty similar to what a lot of companies that are part of the sort of next generation of IT and — we’re sort of seeing the same trend that everybody else, more people moving remove, therefore any remote access products are, there’s a lot more interest at the moment.

    So, we were always about granting access remotely. It was always a workforce that was going to be distributed. That was our typical customer, anyway. So, it’s definitely the same theme, but just more than we were seeing pre-COVID.

    Shimel: Excellent, man. Now, one thing — it’s funny, I just had a conversation with another company within the IDM space, kind of in like an ED directory service, let’s call it, and this popped up. With the people working from home, with the explosion of how many apps and SaaS services, you know, we’re all accessing right now, it’s great to be able to have just a single proxy, if you will. So, I only have to worry about really going once and then on the back end, it connects to all of these services, let’s call them, or apps.

    And so, from my point of view, that’s a great thing. From your point of view, Justin, right, now you’ve gotta hook into all of these different, new apps and services. How do you do that? Is that via API? Is it a one-off for every one you’ve gotta go into? You know, what’s involved there if I bring you — you know, some app you guys haven’t encountered before?

    McCarthy: Yep, sure. So, I do, there is an important distinction here. There’s a generation and a category of products that you might call them cloud brokers, right? So, cloud access security brokers, that category where you have a workforce that needs to access Salesforce, needs to access another SaaS application. We consider that sort of part of the market to be something that’s necessary but not our specialty.

    Shimel: Not your place.

    McCarthy: Yeah. So, our specialty is, again, it’s that staff where there’s probably an engineer or somehow technical, there’s a technical name in their role somewhere, and they need access to things that aren’t webpages. And so, for that, the procedure is — hey, I’ve got this maybe let’s say even legacy database or I’ve got this type of terminal access that we do that, let’s say we’ve got a lot of machines that are connected via VNC or something. So, and let’s say that’s not on our official supportive protocols list yet. It’s as simple as, we do an intake, we understand the protocol, we add it to the product — that’s it.

    Shimel: Okay. So, you guys do that. I don’t do that myself. I don’t have to kinda write to an API or something and make —

    McCarthy: Yeah, no, exactly. Any system that feels like any sort of client server access paradigm, we can model it in our, essentially in our platform, and then begin granting access to it.

    Shimel: Okay. Almost out of time, Justin. One more area I wanted to hit on this one, though, and that is — talk to me about what to set up here, right? Whether I’m doing it on the cloud, prem, a little of both — how big a job is it to get this thing up and running?

    McCarthy: Yeah. So, we also, of course, have the advantage of — like I said, we’re five years old, but that means we’re only five years old. [Laughter] So, we knew it had to be easy, right? Yeah.

    So, yeah, the act of deploying our proxies is essentially roughly turning it on. Because what then the proxies do is, they take over, for example, topics like discovery. So, they discover what host names they can access and they begin exposing it back to it in the administrative console. So, that’s the one aspect that, you know, deploying it is pretty much turning on the software.

    Additionally, because so many of our customers rely heavily on automation for their DevOps, another way to think of it is, if you already have, if you already have a great Terraform setup that you’re happy with, you have a great cloud formation setup that you’re happy with, we are gonna integrate natively with that setup as well. So, it’s going to be, you’re essentially the overlay, your proxy overlay on your existing infrastructure is gonna go in and it’s gonna feel exactly like anything else that you’re familiar with deploying via Terraform or inside your Kubernetes cluster, for example.

    Shimel: Perfect, man. All good stuff. Justin, I promised you we were gonna do 15 minutes, but I blew it — but not too bad. We’re not too bad. Well, we’re gonna have you back on. It’s gonna be a little bit of a continuing series, right? So, look forward to our next conversation.

    You know what I realized? We didn’t even mention the website, though. So, for people who want more information, it’s strongDM, S-T-R-O-N-G-D-M-dot com, right?

    McCarthy: Yep.

    Shimel: And then can get, if they wanna go check stuff out there. And we’ll have you back on real soon and continue this, man. Sounds great.

    McCarthy: Great. Alright, thanks a lot, Alan.

    Shimel: Alright. Justin McCarthy, CTO and co-founder of strongDM here on DevOps Chat. Hey, this is Alan Shimel, and you’ve just listened to another DevOps Chat.

  • Report: Confidence in Digital Transformation Lacking

    Report: Confidence in Digital Transformation Lacking

    Results of a recent survey conducted by the Corporate Board Member Institute shows a majority of respondents see their organizations’ digital transformation efforts aren’t keeping pace with the current business environment.

    The survey polled more than 200 directors of public companies in February, before the global COVID-19 pandemic hit the United States, and the results were compared to PwC’s 2020 Global Digital IQ survey. The results show a lack of confidence in digital transformation initiatives—3 out of 5 respondents admitted their company is behind in their digital transformation processes and within the past three years, only 54% had begun their digital transformation processes.

    The PwC survey, however, shows the opposite: According to those results, 70% of U.S. executives said their digital transformation is ahead of their competitors. That 70% of executives compared to 35% of directors shows executives are more positive in their company’s progress and maintain a goal-oriented view, said Paula Loop, leader of PwC’s Governance Insight Agency.

    The optimism by executives shows that they have confidence in their ability to get things done with digital transformation now, and that they are planning for what is in the present and the near future. The results from directors show a longer-term view—while things currently might not look so good and they say they are behind, they still have the confidence that they can make strides in improving their digital transformation. Directors still believe that they are on or ahead of schedule in other areas such as integrating new technologies into products and services (70%) and training workers for the digital era (67%).

    In interviews conducted post-survey, after the pandemic hit, some directors said COVID-19 will accelerate their digital transformation initiatives. “Regardless of where companies were in digital planning, this pandemic has thrust most, if not all, into some form of digital transformation,” Loop said.

    Even when faced with a global pandemic, the business continues. Competition isn’t slowing down; it’s time to see whether digital transformation processes will follow suit.

  • Knowledge Is Power

    Knowledge Is Power

    I was doing some research over the weekend, and it became abundantly clear that you can find an Ansible script to do pretty much any repetitive task in your infrastructure. This is good news for Ansible users, and the pool of available scripts will, no doubt, continue to grow as critical mass effect kicks in.

    My concern is for those that find a script that does what they want/need, and drop it into their infrastructure. This approach may be a good short-term fix, but is full of potential peril. Even a cursory read of a complex script is insufficient.

    We all know the watchwords of the day are “speed” and “agility,” but take some time to test and get to know those scripts. When (not if) they fail, you’re going to want a clue of what is going on in there to track it down, and you certainly want to understand what is being pulled into your infrastructure. While the community is likely to catch malicious scripts relatively quickly, the inclusion of questionable sources and cases where your infrastructure causes a script to have issues are more likely to make it to your desk.

    The easiest validation cycle is to:

    • Read it for understanding. Know what it is doing, why it is doing it and what it is including.
    • Run it in an isolated environment. A pod, a VPN, whatever, just somewhere that you can control ingress and egress.
    • Scan the results as you would anything in production. Make certain sources are valid for your organization, make certain inclusions are safe and validate that any vulnerabilities in the resulting systems are known and acceptable to your organization.
    • If you can, do runtime testing upon it to catch any real-time changes. Most “changes after install” type of software is either well known or not included, so this step is more peace of mind than mandatory.

    If your thought was “takes too long, not necessary,” the risk is on you. But on the list of weaknesses in DevOps, that mentality is definitely in the top three. “Takes too long” is an organizational concern that is different everywhere. “Not necessary” is only true until it isn’t. As an IT professional, having at least a passing familiarity with the environments you are creating is part of the job. Fail to do it at your own risk.

    Much like there are trusted sources for the various types of repo we access, trusted playbook developers are a list you can curate. I know of a few that, in a pinch, I’d be willing to drop a script from into my architecture with only a cursory review, then give it a more thorough going over later when there is more time. But I know that because I’ve read their scripts, and I get that they are also careful.

    While I have Ansible scripts on my mind because that’s what I was looking into, this advice applies to any and all automation scripts that pull from outside sources. Python and Node do a ton of this too, but only highly complex projects pull from a lot of disparate sources. Ansible and other infrastructure automation tools pull from a variety of sources almost by definition (because infrastructure is complex), so they deserve more attention.

    In the end, automating all the things changes nothing about responsibility. So, take the time to make certain you know what is going on in your environment, and why. If you are really motivated, take the time to sweep through and remove any references you are certain you don’t need — but nested dependencies make the ROI on this type of work minimal, in my experience.

    Meanwhile, you are keeping a ton of servers running and users happy. Keep rocking it, and keep looking for solutions like automation scripts to make you more responsive — just don’t relinquish your authority for the datacenter to random submitter on the internet — because responsibility will still be yours.

  • Review, Review, Review

    Review, Review, Review

    Ossification is an issue in IT, and always has been. It is borne largely out of staff and management knowing what to expect from existing software/infrastructure, and the deep product knowledge that allows teams to make existing systems do what is needed. But this becomes a series of rocks that the ship of progress smacks into.

    Contrary to popular belief, DevOps and other new methodologies are not immune to this problem. Quite the contrary, we’ve spoken with people that say “We’re a Jenkins shop,” which sounds exactly like “We’re an Oracle shop” of a decade ago. The wave just ushered in new tools, it didn’t change tendencies. OK, it did more than usher in new tools, but it didn’t change tendencies.

    So, it’s time for a friendly reminder: Review what you are doing, review cloud usage, review tools in the toolchain, review methodologies, review security posture (which has suffered in this environment for far too many shops) and review customer satisfaction.

    Many organizations used the push of Agile and DevOps to update stagnant parts of the infrastructure and development toolsets. Don’t let them become stagnant again. Just as you don’t want change for the sake of change, you don’t want to stay with one tool or methodology just because it is comfortable.

    This isn’t some easy task that I ⁠— or anyone else, no matter how much they try to tell you differently ⁠— can dictate to an organization. There isn’t a handy list, because no two organizations are exactly the same. Not in toolsets, not in culture and not in appetite for risk. The only thing we can offer is guidance to look closely at where you are, what’s available in a given area ⁠— Application Release Orchestration, for example ⁠— and evaluate the available tools just like you were making a fresh choice and did not have a tool in place. Then do the same for processes. Is this the best process for what we’re trying to achieve? Are there tweaks we can make to it? Should we completely change the process to take in changes in environment that have happened since we adopted this process?

    Finally, if you don’t have someone responsible for monitoring cloud costs, appoint someone. Get them the tools, help them understand where the money is going and what cloud-based server usage is. Could these servers be spun down outside of business hours? Could we follow the sun better by staggering cloud data centers in which cloud servers are active, rather than hosting them always in one location or leaving them on 24/7 in multiple locations? Is one team using a cloud feature no one else is? If so, how does it apply, and are the other teams not using it because they don’t need it, or is there some other solution they’ve adopted?

    Basically, question everything. We’re launching a new project that will be a simple dynamic app. Make a few selections from a limited list, get a summary of what you should do and why. It is all really quite simple. Should we host in a web page or make it a standalone mobile app? If mobile app, what tools for development and what targets? Integration of Git — should it be local or on one of the big providers? Do we want any team member to trigger builds on commit or do we want someone managing branch merging before-hand?

    These are all things we already do on other projects, but we’re digging in and seeing what could be better. What could we improve, and what would the rewards for that improvement be? It takes a bit of time and some discussion. We’re confident we’ll burn through it in the next day or so and come up with a plan for development and architecture that best suits the app, but is informed by where we’re at now. It’s been a fun exercise, to be honest. If nothing else, it gave us a strong reminder that any given cloud provider’s “simple” pricing is not that simple, and we need to pay more attention to app characteristics versus fees.

    You’ve rocked it this far, even kept the lights on during the great shift to working from home. Don’t stop improving the environment though, find innovative ways to make it better and keep clipping along.

  • Cloud and DevOps: CI/CD and Market Analysis

    Cloud and DevOps: CI/CD and Market Analysis

    Companies today are under heavy pressure to deliver software faster and with more quality than their competitors. A set of good features and their reach to customers can increase only when the company releases software updates frequently. As a result, organizations are embracing DevOps and CI/CD approaches to improve their ability to plan, build, test and release applications and features to market quickly with quality and at scale. IDC predicts the worldwide DevOps software market will reach $8 billion by 2022, up from $3.9 billion in 2017. 

    The buzz around continuous integration, continuous deployment and continuous delivery is more than ever today, but in practice, the actual usage of CI/CD seems to be less. It can be because of the shortage of skill set required in DevOps or companies still practicing traditional software development methodologies. Enterprises are not understanding the amount of money they are leaving on the table by missing CI/CD and DevOps automation practices. 

    For many companies, DevOps is something they have to try because their competition is doing so or because it is a trend. This is a desperate attempt without understanding the consequences and basic understanding of DevOps principles. 

    For the most part, it is a disparate set of tools that customers have to connect together for their software delivery that creates chaos around. On the other hand, it is difficult to choose the right tools and understand what are the best practices. That’s why we are starting to see a trend of DevOps companies delivering a unified toolset so that customers have a complete solution out of the box ⁠—without having to worry about finding many different solutions from different vendors.  

    What Is CI/CD?

    Whenever a developer commits and pushes changes to the repository, the CI system will rebuild the branch and run all related test cases to verify that new changes won’t break the existing application and functionalities. 

    Continuous delivery is an extension of continuous integration that helps you deploy your application with a click of a button. It means deploying changes every time they pass CI tests. With this, you can easily automate your build and testing phase and most of your release process as well.

    With continuous deployment, developers will be able to release or deploy software automatically into the production environment. In this stage, no manual code check-ins happen into the app. Code is automatically tested through the CI process for issues, and if none are found, then the code is deployed.

    Why CI/CD?

    CI/CD serves as the best practice for testing and deployment of applications. For the purpose of quality assurance, making CI/CD the single channel to deploy code is the best practice. DevOps teams should ensure that everything is going through the CI/CD pipeline so that the code in testing and production are the same. This will also reduce human error and avoid deploying other versions not being tested by mistake.

    One of the biggest reasons for companies to practice CI/CD today is faster software delivery, which leads to more frequent updates to customers. It makes them feel happy and a constant improvement with frequent releases will ensure enhanced customer satisfaction. This is a competitive advantage because it allows companies to deliver new features more often. It can help companies stay ahead of competitors.

    Passing code through the CI/CD pipeline ensures that any changes made adhere to the established standards before moving to the next stage in the delivery pipeline. Any failure or discrepancy prevents the advancement of such changes to the next step until it is rectified. This simply means this approach of CI/CD ensures that bad code does not get into the production. CI/CD promotes the fail fast, learn fast and deliver fast approach. When you have automated CI/CD in place, the code is run through the CI/CD process constantly with each commit by developers which allows bugs to be caught quickly ⁠— it is easier to isolate the bug since each small change is tested separately. 

    What Is the CI/CD Pipeline?

    A CI/CD pipeline is a deployment pipeline workflow that is integrated with automation. When conducted well, it will minimize manual handoffs and errors to enhance the feedback loops throughout the software delivery life cycle, allowing development teams to deliver smaller chunks of releases within a shorter time.

    The CI/CD pipeline is now mainstream among software companies, and it has become the backbone of the modern DevOps environment. While DevOps lays principles and standards related to the culture aspect, CI/CD focuses on the automation, flow, process and tools. CI/CD scenario has changed with the introduction of containerization and microservices. Now, every cloud vendor has support and integration with tools such as Docker and Kubernetes that help the CI/CD pipeline to scale. 

    Stages of the Continuous Delivery Pipeline

    • Test Automation and CI: This is the important stage where the new features and prototypes are prepared, coding is done and then the code is integrated with the base. With the use of a CI server, the unit tests and packaging is done.
    • Build Automation: This is the stage where the artifacts are pushed by developers (i.e., Dependencies, Docker image) to the registry (i.e., Amazon ECR or Docker hub or any container registry).
    • Alpha Deployments: In this stage, developer checks-in changes. It is the place for developers to carefully see the changes they’ve made and how they interact with each other and affect other systems. Also, here developers can be able to see if they broke anything in the master branch.
    • Beta Deployments: This is the stage where testers carry out manual testing. Manual testing is still required to see the perfection of CI tools. This gives the DevOps team the guarantee that the condition of the application is good and will work definitely as desired when deployed.
    • Production Deployments: Here comes the final stage, where the app goes live.

    What Is the Market Saying About CI/CD? 

    • The search volume has gradually increased in the world for the keyword “CI CD Pipeline” on Google.
    • When Mabl, a test automation company surveyed 500 software testers, 53% of the people said their team uses continuous integration, while 38% embrace continuous delivery and only 29% have adopted continuous deployment. 
    • A DevOps related survey from Codefresh showed that a third of companies had automated more than half of their workloads, but only 1% were all the way there. Almost no one has automated the entire CI/CD process. A plurality of engineering teams have automated less than 10% of the process.
    • The iOS Developer Community Survey is the largest survey of Apple platform developers ever undertaken, where 2,290 people filled in the questionnaire in which CI/CD questions were also a part of the survey. 

    Below are the results that showed a majority of developers are practicing CI/CD when it comes to business apps. 

    Figure 1: Do you practice continuous delivery for your personal/hobby apps?
    Figure 2: Do you practice continuous delivery for your business’s apps?
    • The way forward: Companies will not be able to fully take advantage of containers and DevOps unless they embrace the use of a proper deployment pipeline. Companies will start offering pre-built pipelines to customers, something like JFrog pipelines. There is a need for a unified platform that has all the tools needed to support a CI/CD system ⁠— automation (Pipelines), binary repository management (Artifactory), security (Xray), release/deployment (Distribution), etc. JFrog provides a unified platform.
    • Codefresh conducted a survey and published the results of the survey of 130 developers at the KubeCon + CloudNativeCon Europe 2019 conference ⁠— and the results were a bit shocking. It showed that nearly a third (32%) don’t use any continuous integration or continuous delivery (CI/CD) platform at all. Sixty percent of the survey respondents said their organization has yet to take full advantage of automation to accelerate software development and deployment.
    • The Market Radar Report by GigaOm is a recent research on the enterprise CI/CD solutions where the author compares the leading CI/CD solutions in the industry and rates them depending on different valuation criteria. According to the results, JFrog, Codefresh and GitLab are outperformers as shown below.
    Figure 3: GigaOm Radar for CI/CD. Source: GigaOm.

    The CI/CD solutions considered were AWS, CircleCI, CloudBees, CodeFresh, GitLab, IBM, JFrog, Micro Focus, Microsoft, Red Hat and Xebia Labs. You can download the free analyst comparison report here: GigaOm Radar For Enterprise CI/CD.

    CI/CD is one of the DevOps best practices because it ensures proper alignment between developers and operations. While it enhances automation, developers can push code changes more reliably and frequently. At the same time, the operations team can see greater stability because environments have standard configurations, and rollback procedures are automated. To win the CI/CD game, both dev and ops teams need to develop consensus on the right tools and approaches that are beneficial for the business growth in the long run. 

    Cloud and DevOps Go Hand in Hand

    You can’t do DevOps without the cloud. DevOps won’t have much value without it, and the cloud won’t do much without DevOps. 

    Cloud computing has many definitions, the fundamental explanation of the cloud can be defined as a system that enables and supports the provisioning of infrastructure. Thus, it allows it to be described as code or templates, facilitating the creation of repeatable processes. That is also the basic principle of DevOps, automating the processes/tasks in the software development life cycle to the fullest extent.

    One of the biggest benefits of cloud for CI/CD is the dynamic nature of cloud infrastructure. This is perfect for the ephemeral and bursty nature of CI/CD workloads. Cloud resources can automatically scale up and down based on CI/CD workloads. This allows huge management and cost benefits for enterprises. Enterprise companies don’t need to have their own servers to maintain, they need to increase these servers as CI/CD workloads increase or waste server resources when they are idle.

    Regardless of how your organization defines the cloud technologies and, despite which DevOps routes you travel to achieve digital transformation with the cloud integration, the aesthetics of cloud technologies and services can be easily amalgamated in the DevOps dictionary because they radically complement DevOps principles and processes. 

    For DevOps implementation, Agile principles serve as a driver, as there are shorter release cycles and automation to deliver fast and achieve the deadlines. To implement continuous practices, cloud computing is a great facilitator, since resources are available quickly for all the activities involved in development and application lifecycle management. Agile principles, along with cloud computing and DevOps practices, enable high developer productivity and faster growth in organizations.

    With secured cloud gateways, users get the ability to access enterprise resources easily from anywhere and with any device, without compromising on the security of the network. Letting users access your network from their devices might sometimes seem scary, but the modern cloud platforms have much more to offer, they come with built-in security stacks to help provide administrators with the tools they need to manage and support security.

    DevOps coupled with cloud tech has enormous benefits for businesses employing them:

    1. Increased developer productivity and collaboration.
    2. Faster time to market through quick and easy access to development environments.
    3. Help to automate different repetitive tasks so that developers can focus on the tasks that matter.
    4. Cloud complexity and system maintenance can be incredibly reduced by automation and infrastructure as code approaches.
    5. Increase security with modern cloud platforms and principles that serve to eliminate the manual error.
    6. Help to eliminate downtime through cloud-based continuous business operations. Developers can build stateless applications with automation, which will increase the availability and failover ability, along with increasing business reliability and improved customer satisfaction.
    7. Scale to new heights — one of the main reasons businesses employ cloud and DevOps is to scale their infrastructure and applications as and when needed. 

    Cloud Deployment Models

    When the cloud provider entirely hosts organization’s applications and data, it is a public cloud. With just having an internet connection, the employees of the company employing public cloud can access the applications. 

    A private cloud is when the resources of an organization such as storage, compute and networking resources exist in a provider’s data center. Companies prefer private cloud mainly because of security and for storing highly sensitive data when it comes to running applications. 

    One more modern approach is the hybrid cloud; it is a combination of private and public cloud services. According to the traffic and demand considerations, organizations can make the change. Some customers may have on-prem CI/CD systems. Some of these CI/CD systems can expand their workloads to the cloud in a hybrid setup. This can allow them to realize the benefits of cloud now and not have to do a complete migration.

    Mainly, when there is high demand, workloads can be run in the public cloud, and then when things get back to normal, return to the private cloud. This approach reduces the overhead cost spent on cloud resources. Additionally, the key point is, sensitive information, data and critical applications can be kept in the private cloud. In contrast, less-sensitive data and applications can be stored and run in the public cloud.

    Choosing DevOps Cloud Solutions

    If cloud is like an instrument, then DevOps is the musician who plays it.

    Cloud computing and DevOps play a vital role and are interlocking parts of the IT strategy. Together, cloud and DevOps help IT shift its emphasis from “How far and long can we go without an outage?” to “How often we can deliver new and stable functionality/feature?” or “How fast/quickly can we deploy a new service?”

    Businesses today are looking for ways to digital transformation with the help of the cloud, DevOps and automation practices. Considering the competition in the cloud space, it is overwhelming to see so many vendors and get confused on what to choose. 

    Here, in the State of DevOps Cloud Solutions 2020, you can see a high-level overview of the cloud DevOps platform solutions available today, and what you should expect from vendors in your cloud DevOps journey.

  • An Open Letter From MediaOps

    An Open Letter From MediaOps

    On behalf of all of us at MediaOps, we are so deeply troubled by what is going on in the world around us. As we continue to battle a deadly pandemic and the effects of racial injustice, the idea of devolving into factions and hurting one another cuts to the core of our being. This is a time in which humanity needs to come together. The following quote from former President George W. Bush sums up my feelings about the current situation—a situation that has been evident for far too long.

    “America’s greatest challenge has long been to unite people of very different backgrounds into a single nation of justice and opportunity. The doctrine and habits of racial superiority, which once nearly split our country, still threaten our Union. The answers to American problems are found by living up to American ideals — to the fundamental truth that all human beings are created equal and endowed by God with certain rights. We have often underestimated how radical that quest really is, and how our cherished principles challenge systems of intended or assumed injustice. The heroes of America — from Frederick Douglass, to Harriet Tubman, to Abraham Lincoln, to Martin Luther King, Jr. — are heroes of unity. Their calling has never been for the fainthearted. They often revealed the nation’s disturbing bigotry and exploitation — stains on our character sometimes difficult for the American majority to examine. We can only see the reality of America’s need by seeing it through the eyes of the threatened, oppressed, and disenfranchised.” ~ President George W Bush

    When we initially came up with the idea of today’s TechStrong Con virtual conference, we wanted to show that the tech industry is indeed strong. What made it strong was our desire to collaborate, communicate and share our collective knowledge—that tech would be the light that leads the path forward to surviving and overcoming the terrible virus in our midst. The event was also designed as a charitable event, to raise relief money for global COVID-19 charities—our way of helping by alleviating suffering and supporting frontline workers.

    Now, we find ourselves with yet another challenge. In addition to the devastating impact of the novel coronavirus, we are once again sadly reminded that injustice and prejudice are very much alive and well in our country. We, like most of you, are horrified by what we are seeing on our TV screens. Even here in the tech industry, we need to do better—not just with racial issues, but with all diversity issues. I firmly believe that we can and will do better. I believe that the tech industry can be a beacon, a light illuminating a path to a better, fairer and more peaceful world for all of Earth’s children.

    I pray for peace and for a time when we can venture out again—together—and focus on improving the human condition for each and every individual across the globe.

    Until then, we have decided to split our charitable donations from the proceeds of the TechStrong Conference. $10,000 will be going to the Southern Poverty Law Center, whose mission is to fight hate and seek justice for the most vulnerable members of our society through litigation, education and other forms of advocacy, working toward a day when the ideals of equal justice and equal opportunity are a reality. Another $10,000 will be donated to the World Health Organization to fight COVID-19.

    With today’s TechStrong Con virtual conference and everything beyond, we move forward with the hope that we can and will do better as a nation, as a people and as one world.

    With Peace,
    Alan Shimel
    CEO, MediaOps

  • Survey Surfaces Tension Between Software Speed and Quality

    Survey Surfaces Tension Between Software Speed and Quality

    A survey of 600 software professionals at organizations with more than 1,000 employees published today by OverOps, a provider of software analytics tools, finds the need to ensure quality still trumps the need for speed within most organizations.

    According to the survey results, 70% of respondents say quality is their paramount concern and they would rather delay a product road map than risk a critical error impacting their users. More than half of the survey respondents (53%) said they encounter such critical or customer-impacting issues in production at least one or more times a month. Two out of three survey participants report spending at least a day per week troubleshooting issues in their code, with 30% spending anywhere from two days to a full week.

    Nevertheless, organizations continue to invest DevOps (58%) to accelerate application development. Among those organizations, continuous integration (54%) and continuous delivery (42%) platforms were the top priority.

    Other areas of investment include microservices/containers (45%), static analysis (37%) and dynamic code analysis (27%).

    Nearly half of respondents (45%) said pressure to move fast was one of their top software quality challenges. More than half of respondents (59%) said they release new code/features anywhere from bi-weekly to multiple times a day.

    Despite investments in DevOps, however, a quarter of participants also said that over 40% of critical production issues are first reported by end users or customers rather than internal systems.

    OverOps CTO Tal Weiss said the survey makes it clear there needs to be more focus on software quality. The challenge organizations face is finding a way to achieve that goal while still accelerating the rate at which code is delivered. Too many organizations are measuring the lines of code delivered without taking into account how often they run into issues in production environments because of the quality of the code deployed.

    Of course, whenever a project falls behind one of the first places any organization looks to make up ground is by reducing the amount of time allocated to testing. However, many organizations are also integrating testing within CI/CD platforms to make sure critical testing processes are not skipped in the name of making a deadline.

    It’s not clear whether software being deployed today is any higher or lower in quality than software developed using legacy waterfall approaches. As long as humans write code, there will always be issues. Proponents of DevOps will argue that deploying smaller amounts of code more frequently helps mitigate that issue. If errors are discovered, it’s easier for DevOps teams to not only roll back that smaller update but also more quickly discover the source of any issue. Sometimes that issue may have more to do with the platform the code is being deployed on than the code itself.

    Regardless of the approach to developing software, there is clearly more at stake than ever. As organizations embrace digital business transformation the quality of any software update can have a major impact on the business. The challenge is first eliminating as many of those disruptions as possible and then, secondly, minimizing their potential impact on the business as quickly as possible.

  • Pega Low-Code Platform on Display at PegaWorld iNspire

    Pega Low-Code Platform on Display at PegaWorld iNspire

    Low code enables developers to create applications using visual tools and models. Developers looking for resources to improve their productivity might find Pega’s low-code platform quite helpful.

    Jennifer Gill, senior director of technical product marketing at Pega, joined ASG’s Mitch Ashley for an interview on the benefits of low-code in designing applications.

    During the pandemic, Pega has helped customers develop apps such as a COVID-19 tracker for a large healthcare organization, which was built in less than a week. And in just five days, Pega worked alongside the Bavarian Ministry of Economic Affairs and T-Systems to build a new app that provides COVID-19 financial aid to self-employed workers and small to medium-sized businesses.

    Pega has its own DevOps tool, Deployment Manager, which enables organizations to execute their own unit testing.

    Also built into the Pega platform is the Pega Express Methodology, which guides users step by step from smaller implementations to complex transformations, laying the foundation to easily add new app functionality as business needs change.

    As for the future of Pega, Gill said we can expect more automation and more intelligence built into the platform.

    Meanwhile, you can join her at PegaWorld iNspire, an interactive virtual event taking place Tuesday, June 2, at 9 a.m. EDT, to learn more about the technology behind Pega.

    The event will also feature a live demo on low code, during which attendees will learn how to define core app components and what tools they can use to manage and govern low code at enterprise scale.

    Check out Jenn’s interview for TechStrong TV below to learn more about Pega’s low-code platform.

  • Surviving Through the New Normal

    Surviving Through the New Normal

    As enterprises move from the first phase of the pandemic to the reopening phase, they’re going to have to determine what tech investments going forward will provide the most value in the their new normal.

    Emad Georgy, founder and CTO at consulting firm Georgy Technology Leadership, said that while overall tech spending will remain down, that pain won’t be evenly distributed. Georgy claimed that investments will continue to remain high in the obvious industries, of course, such as healthcare, retail and grocery chains.

    “However, multiple adjacent and dependent businesses investments will also remain high. Suppliers of materials required by these industries, companies involved in their supply chain, companies supporting remote collaboration tools will continue to thrive,” said Georgy.

    Coming off the heels of the economic shutdown, Alex Milowski, platforms researcher and evangelist at database management software provider Redis Labs, said that both people and systems have experienced significant disruptions, and this has hurt their productivity and strained technology platforms in some ways, while for other job functions platform and infrastructure are at over capacity.

    Milowski said organizations needed to strike a balance between the immediate needs of staff, so that they could adjust to the changes in their work and lives and still access critical work systems while also ensuring that customer needs are also met.

    However, now that enterprises are looking forward, how do they ensure that their digital transformation efforts remain in place?

    As enterprises get their footing as the new economic reality settles in, Milowski advised organizations to focus on small wins.

    “Prioritizing projects where one can increase the confidence of the team to function under uncertainty may be the best strategy. New projects may need to be created to address surges in demand via caching or acceleration systems,” said Milowski. “A team might use this time to address auto-scaling systems so they can scale-down as a cost-saving measure. The increased collaboration and creative problem solving will build team confidence in their ability to deliver. With each win, ensure readiness is improving.”

    Within those early successes, teams can then troubleshoot their processes with less disruption to their business.

    “As their confidence grows, they can ease into picking more business-critical and complex projects. In the end, they are more likely to succeed, with less disruption, as their team is now ready as they know how to deliver new digital initiatives in very different contexts. Successive small wins turn into big wins,” said Milowski.

    Georgy indicated that such uncertain times require a sharp focus and prioritization.

    “Financial insecurity often leads to sharpened discipline which one could argue we should have anyway in an organization. Unfortunately, many companies are plagued by ‘management by assumption.’ That is the practice of managing and deciding based on opinions or second-hand knowledge because they don’t have time to [dig into] the weeds,” he said.

    It’s time to prove concepts out. Georgy added that it’s more important than ever to make data-driven decisions based on experiential learning.

    “Opinions are no longer welcome. Every person at the decision table must justify their decisions with data, with real-world experience and with action,” he said.

    That can be done by CIOs as they track their changing customer base.

    “Customers are changing how they spend and re-evaluating what is important to them and this will be reflected in roadmaps as well. Now, more than ever, feedback loops, usability groups and touchpoints with customers to understand this changing dynamic is key to evaluate new approaches and priorities in the roadmap,” said Georgy.

    John Belden, project execution advisory services practice leader at UpperEdge, stated that now is the opportunity for CIOs to lead in a way that hasn’t been readily possible in more than 20 years.

    Belden advised CIOs to:

    • Take the lead: CIOs can win back the seat at the management table that they enjoyed during the Y2K era. By proactively reaching out to work with counterparts in HR, marketing and supply chain, CIOs can shift from order-taker to problem-solver, which will also help in prioritizing projects.
    • Determine an approach to road-mapping: There are likely to be three different strategies to road-mapping and navigating this time:
      1. Reinvent: This approach establishes a clean sheet of paper and takes a more traditional approach. Companies that could never get the cash or attention to build a roadmap, might have this work thrust upon them if corporate boards demand a pandemic risk mitigation plan.
      2. Revise: This would involve the shuffling of the existing portfolio, some reprioritization and confirmation of direction from the various vendor’s strategies.
      3. Accelerate: Some companies may have already charted a course that accounts for assumptions of a new world order. In these cases, it is likely that CIOs will be asked to accelerate to either leap-frog competitors or solidify their competitive position.
    • Transform vendor engagement strategy: The onslaught of vendor marketing initiatives and client targeting strategies could end up being like the wild west with cloud providers bypassing traditional IT channels to market their wares. CIOs need to work proactively with their business counterparts to set the ground rules for engagement and craft a strategy that motivates suppliers to assist clients in developing their own strategies that can be realized quickly and efficiently. Developing a long-term view in managing the short-term downtime will, in the end, pay dividends in executing during this economic downturn.

    Short-term survival with an eye on meeting long-term goals is key to survival, and in the months ahead those enterprises that successfully meet that balance will set themselves apart.

  • The Best Approach to Help Developers Build Security into the Pipeline

    The Best Approach to Help Developers Build Security into the Pipeline

    Speed and agility are at the core of digital transformation and DevOps culture, and have quickly become a business imperative for organizations that want to remain competitive. Speed cannot come at the sacrifice of security, though. The pace of software development requires that security be baked into the code from the start rather than tacked on after the fact. Developing secure code fast requires empowering developers with the skills and tools they need and building security into the DevOps pipeline.

    Embracing DevSecOps

    DevOps culture and the drive to work faster and more efficiently affects everyone in the organization. When it comes to creating software and applications, though, the responsibility for cranking out code and producing quality code falls on developers.

    The pace of DevOps culture doesn’t allow for anything to be an afterthought. It’s important for developers to support security directly as a function of application development in the first place, and to operationalize security within the continuous integration/continuous deployment (CI/CD) pipeline.

    Unfortunately, traditional education does little to prepare them. It’s possible to get a PhD in computer science and never learn the things you need to know to develop secure code. As organizations embrace DevSecOps and integrate security in the development pipeline, it’s important to ensure developers have the skills necessary. You also need to focus on both the “why” and the “how” in order to build a successful DevSecOps training program.

    Don’t Just Check the Box

    Not all training is created equal. Consider why you’re doing the training and the outcome you hope to achieve rather than doing training for the sake of training. Many organizations focus on training developers in secure coding practices from the perspective of compliance. It’s crucial to engage developers in a meaningful way, though, and not just check a box.

    Many compliance frameworks, such as PCI-DSS, require ongoing application security training, but compliance training often reinforces the wrong lessons. Developers learn the most expedient way to check the box and achieve compliance rather than learning the most efficient way to develop secure code. This approach also causes developers to feel like the security team looks down on them or doesn’t understand the challenges they face or the expectations they have to meet.

    The Carrot and the Stick

    How you do security is also important. Training works better when developers feel like they are part of the process and when they have a reason to want to excel.

    For nearly everyone, doing something in practice reinforces lessons better than just reading content or listening to a webinar or video. Interactive labs are more engaging and provide feedback as developers go through the training. They can practice writing secure code with guided practice that is self-paced. They can also get hands-on experience exploiting vulnerable applications, then patching them back up.

    You should implement developer training that creates incentives for developers by gamifying training. Create custom Capture the Flag events, track individual progress and provide a leaderboard that enables healthy competition among the developers.

    You also want to provide developer training that is relevant to your organization’s preferred coding languages and business objectives. The training should teach skills and strategies that are applicable to the code your developers work with and give them tools they can use immediately to improve the security of the applications they’re working on.

    Speed is essential for businesses to maintain a competitive edge today, and security is more important than ever. Make sure you have the training in place to help shift application security knowledge left and integrate security to mature DevSecOps practices.