Through centralized log management, organizations can consolidate all log data into one central, data highway and directs logs wherever they need to go
The digital transformation wasn’t gradual. It came crashing into industries worldwide in response to safety restrictions around the pandemic.
Nearly a third of Americans are working remotely in light of the pandemic—drastically increasing the external users—with no signs that employees will be returning to the office full-time post-COVID-19. A recent PwC survey found that 83% of employees want to work remotely at least once a week and that 55% of employers anticipate their employees will do so even after the pandemic.
Companies have implemented new and creative solutions to deal with the spike in remote access: VPNs and SSL connections through web applications, to name a few. However, many of these solutions were only a bandage that won’t suffice for long term remote access.
There is one thing amid all these changes that can become an increasingly large problem if left unaddressed: logs. Logs are collections of data that continue to be collected whether users are in the office or in their living room. Without centralized log management, this data can put organizations at a critical security risk. As the digital transformation takes industries by storm, it’s important for organizations to remember the importance of managing logs.
Today’s Log Landscape
When a company’s remote workforce jumps from 50 to 5,000 in a matter of weeks, things change. Compared to in the office, logs at these companies have jumped by 10,000%. Remote work generates logs on security access points, remote access, server logs, terminal services and application logging—all of which are fed into an organization’s security information and event management solution (SIEM).
This jump is creating and revealing more blind spots to companies, which proves how difficult it is for administrators to increase the rates for their security monitoring tools to reach that level without drastically upping their company’s budget for its SIEM. Even Microsoft and network providers are running into issues with so many changes happening at the same time. Additionally, companies have to worry about privacy laws, making sure all personal data is encrypted and secured.
Centralized Log Management
Organizations should implement centralized log management (CLM) to consolidate all log data into one central, data highway that collects all logs and directs them wherever they need to go. CLM solutions reduce SIEM costs once SIEMs are no longer effective log management tools.
Dropping all logs into a SIEM spikes costs, so oftentimes only a portion is collected, which creates fragmented or incomplete pictures and impacts security monitoring and incident response. CLMs lift the burden of having to hire staff, provide training and support for SIEMs. CLMs also reduce the costs organizations would incur with their SIEM providers, as well as the risk of endangering the SIEM infrastructure by storing unmanaged logs.
Fragmented data collection can become a unified data collection with a data highway. Organizations can now filter unruly data and deliver only what you need. This helps overcome the age-old strategy of letting separate teams have their own sources of data, which could instead be directed to the appropriate team via your data highway. The data highway lets you collect once and use it many times, where it’s needed.
Parsing: Cleaning up the Data
Once logged, data needs to be parsed. To prime your data to be parsed for specific items, unnecessary and unwanted information must be filtered out. This diminishes the storage space logs take up and increases the usability of the data.
One example of superfluous information is the timed mark that many applications add into the log of their system to show they are online. Unless a security auditor will need to see this, there is no reason why an organization should be paying to store it in their SIEM. Administrators are even able to filter out all extraneous text and add parsing for specific events. This quickly and easily reduces costs that are likely spiraling out of control during this time.
Parsing, filtering, masking and other transformation techniques in your data highway allow security teams to overcome privacy issues and filter out personal information that shouldn’t be distributed. Resolving this problem could become crucial as more and more personal data is being collected than ever before, and as privacy laws are becoming stricter.
The Data Highway
Build your dream team to utilize your new data highway to its greatest potential. Not everyone reviewing logs will be SIEM experts or as skilled as a Linux or UNIX administrator (or even one at all). Build your team to be able to easily operate your new data highway, because you don’t want it to be gathering dust on the shelf.
With your new data highway, you’ll be able to optimize your SIEM, increase your likelihood of meeting compliance requirements and be able to log from more places with easy searchability. With that encrypted data store, your compliance officer may even be able to sleep at night. Beyond the SIEM, you’ll be able to send your data anywhere: Kafka, MongoDB, any database, big data systems and more. Don’t just optimize your SIEM; build your data highway and collect those logs once, distribute them where they need to go and cut costs with centralized log management.
So, in this crush of new technologies spiraling into the new digital transformation age, don’t forget the importance of managing your logs. IT and security admins shouldn’t be in the position of going to company management to inform them of uncontrolled SIEM costs. They can be managed and reduced without losing their effectiveness by simply feeding to the SIEM only the data that needs to be there.
Continuous transformation in IT operations is more than just an industry buzzphrase. In fact, continuous transformation is a critical survival tool for any cloud and IT solution landscapes today. To achieve continuous transformation, innovation must continue well beyond a migration to the cloud. This continuous innovation during day-to-day IT operations is the most critical aspect to achieving month-over-month best-in-class operational benefits.
Simply “lifting and shifting” systems to the cloud without modernizing precludes most of the key benefits that your systems can potentially deliver over the long term. For example, some of the outcomes of this approach, including bug fixes and other common errors, cause downtime and delays that businesses cannot afford in these highly competitive environments. In addition, unplanned downtime and disruptions impact revenue and can damage brand reputations, both of which detract from a business’s ability to compete and win in their market.
Proactive vs. Reactive
To stay ahead of the pack, companies must shift from a reactive to a very proactive posture. Error prevention is far more effective than fixing errors and resolving issues as they happen. To this end, companies should be leaning on service providers that proactively cover the entire application and infrastructure landscape, end to end, through customized, out-of-the-box solutions. For example, proactivity is rapidly enhanced by including predictive analytics and other fault-finding algorithms in software, such as:
Analytical anomaly detection.
Cloud-enhanced and optimized monitoring templates.
Self-healing automated reaction, from disk extensions, cluster and scaling groups to ensure an issue does not result in downtime, simply a post-event investigation.
A company’s IT needs are also continually changing as business landscapes evolve. For example, being on the cloud and using service level agreement (SLA) measurement has now advanced to become mission-critical in two areas: bottom-up technical SLAs (as per usual) and now, more importantly, top-down business transactional SLAs.
Here are some ways IT could streamline its operations and deliver the most value back to the business:
Operations Analytics – An operations analytics tool allows for capacity planning, monitoring usage trends and patterns over time. Should deviations from the anticipated usage occur, IT teams can react immediately, implementing remedies before the situation escalates to an incident. This early intervention could be done either manually or automated. Automated scripts, triggered by predictive alarms, can restart services and adjust virtual resource allocation or any other remedial action necessary.
Predictive Analytics – Future planning is essential to successful business operations. Predictive analytics improves on this by using precursor and antecedent information to predict system failure with an associated confidence level. IT teams know when resources operate outside their anticipated range and how likely they are to fail within the next period. System failure is usually associated with a surge in user activity. This is not easily predicted, driving the need for advanced predictive analytics. Armed with this information, IT teams can carry out preventative maintenance on data centers and associated systems, such as that done for manufacturing machines in industrial applications.
Automated Self-Healing Systems – By combining artificial intelligence and machine learning, digital innovation has made it possible for business systems to self-heal. Advanced, automated software packages monitor business systems, finding errors and fixing them without human intervention. These systems address performance variations and restore outages as well.
Through self-learning algorithms, the software learns and understands the normal business operations and its reactions to irregularities and errors. Using this information, the software reacts appropriately when it detects errors, automatically restoring the business system to normal operations. These automated, exponential self-healing packs utilize innovative, continual logic learning as part of their standard software package. These systems also resolve issues in a fraction of the time it takes through traditional manual intervention. Typically, the end user doesn’t even realize that an error has occurred, improving the user experience dramatically.
The implementation of self-healing systems is relatively quick and can be done in as little as four weeks. As a result, IT teams will have access to advanced troubleshooting and automated diagnostic, enabling fast, root-cause analysis of any errors that occur—implementing the solution through guided prompts, documents the resolution for future reference. And, if the same error occurs again, the solution will automatically be executed.
Automated self-healing systems offer a range of benefits, including business and IT cost reduction, decreasing unplanned downtime and risk-free digital footprint expansion for continuous transformation. IT professionals can work strategically, delegating mundane and repetitive tasks to automated processes, freeing time and resources to carry out more advanced tasks aligned to business goals.
Postman today announced it is making its namesake platform for managing application programming interfaces (APIs) available via a browser to make it easier to share and inspect APIs. Previously, Postman required DevOps teams to download a desktop application to access the Postman platform.
Kin Lane, chief evangelist for Postman, said agent software developed by Postman makes it possible to create a proxy application to facilitate API request-sending at scale that overcomes the cross-origin resource sharing (CORS) limitations of browsers.
DevOps teams can now simply attach a URL to an API that is shared with any other member of the team. Clicking on that URL exposes the API in a way that makes it possible to not only visually inspect it but also employ the Postman platform to make sure rules and policies have been applied appropriately.
That capability also makes it possible to onboard new users to an API project in addition to eliminating the need to manage updates to the desktop application, added Lane.
Now that more organizations have adopted an API-first approach to building and deploying applications in the age of microservices, those APIs need to be managed as discrete projects. Postman provides a means of achieving that goal now through a browser interface that can be accessed more easily by members of DevOps teams working remotely.
Postman claims its platform has now enabled more than 1 billion API requests, with more than 48 million API collections now running on Postman. Overall, the company claims there are now more than 11 million users from roughly a half-million organizations on its platform. As the number of microservices-based applications being deployed increases, the number of internal-facing APIs that need to be managed increases exponentially. New functionality can be added to the application without changing the API. In fact, changes to the API are likely to be more disruptive than changes to the application.
At the same time, cybercriminals are now targeting APIs that are often misconfigured in a way that exposes potentially sensitive data via an open port. As such, security teams are starting to focus more on ensuring processes are in place that ensure APIs have been reviewed before being deployed in a production environment.
Fresh of raising another $150 million in funding to create a $2 billion valuation, Postman has emerged as a major API management platform in a crowded field that has experienced a wave of consolidation over the last few years involving acquisitions made by Red Hat, Oracle, Salesforce and Microsoft. Each of those acquisitions was made to enhance the API management capabilities of a specific platform. However, it would appear a large percentage of organizations prefer to manage APIs independently of any specific platform.
Clearly, APIs are core to the implementation of DevOps processes. If those APIs are flawed, the impact on DevOps process can be far-reaching. Continuously validating APIs as they are deployed and updated is not just a best practice, but it’s also a matter of survival at a time when complex distributed application environments have never been more loosely coupled.
In this interview for TechStrong TV, I am joined by strongDM CEO Elizabeth Zalman and mParticle CISO Dave Anderson. Dave shares with us how mParticle uses strongDM proxy services to rapidly enable the expanding mParticle team to access infrastructure, assets and applications necessary for mParticle to fulfill its mission to its customers.
With the rapid growth of mParticle, the company needed a solution that would allow it to onboard its new employees and locations seamlessly. strongDM gives mParticle this capability. Have a watch of the video and follow along with the transcript to find out more.
Transcript
Alan Shimel: Hey, everyone—back here for another segment on TechStrong TV. I am joined once again by my friend Liz Zalman at strongDM. Hey, Liz, how are you?
Elizabeth Zalman: Hi, Alan. I’m well, thank you.
Shimel: Good to have you back on. And joining Liz and I today, another guest, is Dave Anderson. Dave is the CISO at mParticle. Hey, Dave—welcome to TechStrong TV.
Dave Anderson: How’s it going?
Shimel: Going great. Not as great as you are. Dave’s coming at us from a sailboat today and we’re all stuck in our homes and offices, but hey, the life of a CISO—and you guys complain.
Anderson:[Laughter]
Shimel: Anyway. You know what, we—yeah, I don’t know, it’s hard to make that less glamorous, Dave, but we’ll give you the pass. Liz, for those who haven’t seen some of our previous interviews with you and the strongDM team and some of the customers, why don’t we start off, give our audience a quick background, who’s strongDM, what you guys do?
Zalman: Sure. Strong is a proxy and it lets people manage and audit access to any firewalled infrastructure—servers, databases, Kubernetes clusters, RDP, firewalled web apps, HTTP endpoints. So, essentially, instead of managing keys and creds, you give people access to strong, and then it talks to the target systems on your behalf, so you get access control and then auditing through the proxy itself.
Shimel: Everything you expect from your proxy—great.
Zalman:[Laughter]
Shimel: And it’s sort of proxy as a service, if you will, yeah?
Zalman: Yeah, there’s a portion of it that is hosted, the control plan itself, and then the rest goes through your own hardware.
Shimel: Got it. And Dave—
Zalman: Or whatever your virtual hardware is these days.
Shimel: Well, yeah—no one uses hardware. Through your own infrastructure, how’s that?
Dave, talk to us about mParticle.
Anderson: Yeah, so, mParticle is a customer data platform. So, what that means is, our customers are able to use our platform to ingest pretty much anything, any data about their customers, about the activity that’s going on on their websites and mobile apps into the mParticle platform, and then we’re able to give our customers the full control of being able to fan that out to any of our different integration partners. So, there’s that, as well as being able to do things like data quality, match identity resolution, figure out where a particular user is, what sort of ways you want—like, how they’re interacting with their particular application or whatnot.
To be honest, we have customers, like, in a bunch of different verticals, and they all use the product a little differently, and it’s—we’re continuing to grow and innovate and figure out different ways of kind of helping our customers along with their data journey.
Shimel: Excellent. And, you know, that kinda mission is just so attuned with what I think companies are looking for today, right, which is—you know, there’s so much data out there. There’s so much—you know, do you want it all, what are you gonna do with it all, what makes sense, what doesn’t make sense? But the idea of being able to access that, analyze it—hopefully, with as much automation as possible—is what it’s all about.
Of course, it also creates—as a CISO, you know this—it creates tremendous responsibilities and potential pitfalls from a security, data, access, compliance point of view. But it also, you know, to the strongDM mission of proxying through firewall to assets, whether those assets are remote workers who have to access, you know, data in the cloud or on-prem or wherever or just whether they’re remote or not, access incorporate assets, which, in your case are, in some cases, I’m gonna assume, a lot of PII kind of data.
Dave Anderson, mParticle
Anderson: Exactly.
Shimel: This is a potential security nightmare. This is what keeps CISOs up at night on their boats. So, talk to us, Dave, what is—you know, how does strongDM help you sleep better?
Anderson: So, naturally, we’re a data collection—data collection and distribution company. So, we have a lot of data, a lot of data split up into a lot of different databases, and we have to have very tight access controls for those databases. So, one of the things that strongDM gives us the capability of doing for—when any sort of support people or operations people need access to a particular database or data set within the kinda mParticle back-end, we’re able to utilize strongDM to give us the ability to have secure access to that, that is able to be tied back to the individual who’s doing the work, everything is audited, everything’s logged, we’re able to generate reports for compliance.
So, it gives us the capabilities of not having to give our, like a support person, for example, give them a direct access to the database. They have, like, a nice tool they can use, everything is integrated nicely on the desktop, and everything is integrated well with all of our identity management platforms as well.
Shimel: Excellent, excellent. So, Dave, I think we—you know, we get what you’re doing there, we get what the potential risk is. And we’ve done a few interviews—in full disclosure, we’ve done a few interviews with some of the strongDM clients in fintech and other verticals. What we haven’t done is kinda peeled back what was—I mean, using a proxy, I think a lot of our audience has probably used a proxy one way or another.
But I want to peel back now, in the case of mParticle, walk us through how you guys sort of say, “Okay, we’re gonna use strongDM.” How did you set it up? How did you deploy? How do you manage it, right? How does it give you the warm fuzzy feeling you need to know that you can sleep well at night?
Anderson: Well, to be perfectly transparent, I was—I’m pretty new at mParticle, so, I wasn’t here when—
Shimel: So, you inherited it?
Anderson: Yeah, so, I inherited it. But I actually am a pretty early strongDM customer from my last job at Greenhouse Software, and so, I’m very familiar with that aspect of it. We used it for similar purposes back then. Back at Greenhouse, we had a lot of support personnel that were—and kinda data quality engineers that were using the strongDM platform to access our databases within AWS. And similar here, we want to have—we try to keep as much, the access as restricted as possible. We believe in the principle to release privilege, and separation of duties.
Shimel: Sure.
Anderson: So, with that, we need to have our networks deeply, deeply isolated. The databases live kinda deep into the network, not even having access to the outside world. And with that, the only way to give somebody in support access to that database traditionally would have been giving them VPN into that environment and then them having to actually install the different tools and having to manage authentication and access control. And even then, what would happen is, we would also lose visibility into what they did on that database. Like, what queries did they run, what data did they see? Because it’s not even necessarily a kinda everyday type of thing for someone to have access to the data itself. We tightly, tightly control who has access to what data, and using a tool like strongDM is pretty much a requirement for that.
Shimel: Yeah. I mean, look—and I’ll try to put it in layman’s terms for our audience who maybe aren’t as familiar with this stuff. When you’re using a VPN, they call it a tunnel, right, a tunneling tool. Because really, what you’re doing is, you’re punching a tunnel through, whether it’s your firewall in your infrastructure, and it’s an encrypted tunnel at that, right? So, everything that takes place within that tunnel is encrypted.
And so, when I connected to a database via a VPN, you may see that I did connect—oh, yeah, that’s Alan’s client and he connected to the database. But in terms of what data was in that tunnel and what—you know, you really don’t, you don’t have visibility there, by its very definition, right? On purpose. It’s not a byproduct, that’s how it’s supposed to be. And you don’t—you know, you can…it’s just, that’s how it was designed.
And so, that doesn’t really play well, you know, in the areas of DLP and you wanna make sure data’s not ________, you know, taken out. It’s a problem. So, now, strongDM helps you solve that, is what you’re telling me, because now we can see, you know, it’s a proxy, but on the backside of the proxy, that goes into the firewall and into the trusted network as we used to call it 100 years ago when I was in security, right? When you go through that into the trusted network, you can still see where Liz went or Alan went or Dave went, because it’s not that tunneled, right? It’s not that encrypted tunnel through there, it’s more of the proxy. I remember when we were NAT-ing firewalls, right, a long time ago, and it was that same thing—at least I could match up this IP to that IP, the behind the firewall versus the public IP, you know, private IP, public IP. And so, you had some of that then.
Then, on top of it—look, giving people a VPN, with everything going on in COVID and remote workers, you know, and all we’re hitting, and of course they’re not just hitting your database, there’s also SaaS apps that they need to hit and everything. A VPN is—I’m not a big fan of VPNs in today’s world, if you can’t tell, okay? I just—it don’t make sense. I mean, and then, and the whole idea of VPN-ing back into a central kinda office to go back into the cloud also kinda, I mean… You know, a friend of mine, I know a guy named Jay Chaudhry who is, of course, the CEO and Founder of Zscaler—he used to rail from the very time the cloud-first started coming on the scene big, 2006-’07, he was saying back then that VPNs were, you know, the time has come, but here we are, 2020—same thing.
But, Dave, how easy was it to set up the strongDM proxy, and what kind of visibility is it giving you?
Anderson: I mean, setting up strongDM is really easy. There’s a couple of pieces of infrastructure that you put into your environment, and that would all depend on how you deploy your infrastructure. So, there’s—I’m trying to remember the exact terminology. Like, a gateway and a—what was that?
Shimel: Liz, can you help him here?
Anderson: Yeah.
Zalman: What?
Shimel: Can you help him out, here?
Zalman: I ________. I would never leave my friend hanging—never. [Cross talk]
Anderson:[Laughter] Yeah, so, you deploy that infrastructure that, basically, that sits in your network and you have, and then it talks back to the strongDM portal and so, the strongDM clients actually know who to talk to, like, what IP addresses and what databases it has access to. You go through the strongDM UI or you can use their API, depending on your preference to set up different databases and set up the credentials in there and all the users and what users have access to what databases and what roles within those databases they have access to. And then there’s a client that runs on the person’s laptop, and that client, they’re like, you’re talking locally to that client and it’s magically on the strongDM back end, like, routing everything around to the right place and makes it extremely streamlined for the end user, because they just have this little control panel down there, like, in the bottom of their screen that lets them connect to the particular database, and it’s really, really ridiculously easy to use.
Shimel: Very cool. Now, as part of the role in CISO, you’ve always gotta be thinking not if, but when we have an incident, right? I’ve gotta be able to do forensics, I’ve gotta have an audit trail, right, I’ve gotta be able to figure out, what the heck—I have to show people what happened here, did we take reasonable steps, right, and stuff like that.
What is it, in terms of audit trail and forensics, how does strongDM help you there?
Anderson: So, it shows us who connected to what resource when, how long they were connected, what they did, what sort of careers they were in, what sort of other kinda SQL comments or whatever the database may be, and be able to produce that in near real-time, as well as have logs to go back to if there was an incident that we would know what data was accessed by a particular individual.
Shimel: So, that’s kinda the control plane that sits in the cloud, Liz, or that’s local to the client?
Zalman: The auditing happens through the gateway. So, when the request hits the gateway, it actually deconstructs it in order to provide the audit trail—so, that stays resident in Dave’s network, yeah.
Shimel: Excellent. So, we don’t have to worry about access to strangers to that.
Zalman: Yeah, no, it’s his data. We don’t wanna touch it. [Laughter]
Anderson: Yeah, that’s one of the most attractive things, actually, was the fact that the data stays in our network. strongDM operates the, how things actually get connected, but as far as, like, once you’re in that network, it’s, everything stays within there.
Zalman: Cool. Alright, sounds great. Dave, one other question. With COVID and everybody working remote, I know—look, I mean, strongDM, from what I’ve seen, has built a…not built, but while there are plenty of people, obviously, suffering as a result of COVID and my heart goes out, I’m sure as you guys, too, to people who have lost loved ones and are sick and have lost jobs and money and all of the bad things that are happening with this. The fact is, you know, with remote workers being more and more common, solutions like a strongDM are thriving, right? Are being rapidly adopted. Not because they’re nice to have, because you gotta have something like that, right? So, I’m wondering, what are you guys seeing at mParticle and a similar kind of thing as you’re going remote?
Anderson: Yeah. I mean, thankfully, we were really well-equipped for going remote. A lot of the engineering team is distributed to begin with. We had people in Seattle, Florida, Texas, and New York, of course. But we were able to transition to it pretty seamlessly. We just spend a lot more time on Zoom.
Shimel: Don’t we all?
Anderson: Yeah. [Laughter] Yes, but having the technology in place for being able to securely connect to remote networks, remote resources is definitely, it’s a requirement nowadays. I mean, especially with—you can’t, you don’t have a perimeter anymore. There isn’t that network, the whole concept of having that network firewall that was sitting there and protecting everything is kinda dead now, especially with, since everybody’s working from home. I mean, and VPNs, as we were talking about before, only give you so much. There’s only so much flexibility you have with how you can protect your network and segment your network to make a VPN be as flexible as a platform like strongDM.
Shimel: Look, I thought network firewalls were dead in 2007, right? I remember the first time I saw a Jericho—I don’t know if you remember this, Dave, but do you remember the Jericho project? Did you ever hear of that? That, you know, they were the first ones to talk about the de-perimeterization of security and micro-perimeters and personal perimeter and all that stuff. That whole moat and castle setup that the network firewall played in and the VPN was sort of a bastardized child of, you know, that disappeared when we got mobile devices and people started going mobile. Sounds like a Who song—“Going mobile, mobile”—anyway. But yeah, I don’t disagree with you.
Liz, let me ask you. I mean, mParticle, is this sort of the—it seems like it’s right in the sweet spot for what you guys are doing, then, right? This is the mission.
Zalman: This is the mission, yeah, and it’s, and actually, Dave, shifting from—I mean, what do you call Greenhouse, ATS?
Anderson: Yeah.
Zalman: It’s a form of data management, actually, shifting into customer data. It’s a vertical that I hold dear, because I actually started my career in ad tech, and what he’s describing is what I wanted a decade ago. So, like, I personally love the fact that mParticle is a customer. [Laughter] There is simply no place to store that stuff and then to link it across various touchpoints—it never came to fruition.
But yeah, a company that is distributed, that isn’t hyper-growth, it has large corporate clients who have, I’m guessing—Dave, tell me if I’m wrong—contractual requirements with respect to security and pen testing in various attestations.
Anderson: Of course, yeah.
Zalman: Yeah. [Laughter] Yeah, we do a good business in that area, and it hits all those things.
Shimel: Very cool. Guys, we’re about out of time. Dave, I appreciate you taking time out of your busy day on the boat to join us here. [Laughter] All kidding aside, man, it actually is a very great socially distanced way to get work done.
Anderson: Yeah.
Shimel: Truth be told, I’m supposed to be on a boat tomorrow and I canceled, because I had some stuff come up, and [Cross talk].
Zalman: Alan, it’s not that strongDM helps Dave sleep better at night, it’s those waves in the harbor, too. [Laughter]
Anderson:[Laughter]
Shimel: Yeah, well, that—right, they’ll help you sleep, either way. They’ll help you sleep well, as well.
Anderson: Yeah.
Shimel: I’m not gonna go there, though, Liz. You know, leave Dave alone.
Anderson: It’s also my alarm clock in the morning. [Laughter]
Zalman:[Laughter]
Shimel: Yeah, that’s exactly it. You know what, alright, the guy’s on a boat, there’s worse things. It doesn’t make him a spoiled person. I don’t wanna get—you know what, but for all those people who say CISOs are underworked and overpaid, as Dave’s living here on the boat, that’s not true. CISOs are overworked and underpaid.
But anyway—Liz, thanks for joining us.
Zalman: Thanks, Alan.
Shimel: We’ll hopefully have another interview with you soon, maybe.
Zalman: I think we have one on Friday.
Shimel: Very cool. Dave, thank you for joining us—great, continued success with mParticle. Sounds like a great business and a great use case here for strongDM, and enjoy—enjoy your time. Stay safe and stay well.
Zalman: Thank you for having me.
Shimel: Thank you. Hey, this is Alan Shimel. You just watched another TechStrong TV segment. We’re gonna be right back with another guest.
CircleCI today launched a developer hub as part of an effort to further advance adoption of DevOps best practices.
Company CEO Jim Rose said CircleCI developer hub provides access to a set of resources for optimizing continuous integration/continuous delivery (CI/CD) pipelines. In many cases prior to the onslaught of the COVID-19 pandemic, organizations had only partially implemented best DevOps practices, noted Rose. The CircleCI developer hub will make it easier for those DevOps teams to extend the scope of those processes while serving to educate IT teams that have had limited exposure to DevOps workflows, he said.
The CircleCI developer hub provides access to, among other things, CI/CD configuration optimizations and pre-built packages, migration guides and documentation. There are also reusable snippets of CircleCI configuration code, customized open source Docker images that can be used on any platform, and command-line interfaces (CLIs) and application programming interfaces (APIs).
Later phases of the developer hub will include an orb development kit to help users quickly create new orbs using CircleCI CLI commands. An orb is a software development kit (SDK) that simplifies integrating the CircleCI CI/CD platform with third-party tools and platforms. CircleCI also plans to provide a much more streamlined search engine experience for CircleCI documentation.
In general, Rose said DevOps is becoming more challenging as organizations attempt to orchestrate the building and deployment of monolithic and microservices-based applications constructed using container and serverless computing frameworks. There are plenty of instances in which deploying a monolithic application is still more appropriate, so IT organizations need to be able to create DevOps workflows capable of spanning multiple classes of frameworks and platforms, he noted.
Making matters more complex is the testing of microservices now needs to be integrated within production environments, added Rose. It’s not really possible to completely test a microservices until IT organizations see what impact it might have on other microservices that have already been deployed in a production environment, said Rose.
It’s not clear what impact COVID-19 has had on the productivity of DevOps teams. It might be easier for developers to generate more code working from home than in the office. However, generating quality code at the right time during a project requires a lot more orchestration when members of the application development team are highly distributed. More than a few organizations either already have or soon will be tuning DevOps workflows to align with the so-called new normal.
Of course, there are plenty of places to find tips and advice when it comes to building and extending DevOps workflows. The challenge is creating workflows that are not only flexible and resilient but also simple to implement and maintain.
Company CEO Sven Efftinge said DevOps teams will now have the option of deploying Gitpod themselves as an alternative to the existing cloud service provided by the company.
Designed to be used in conjunction with repositories such as GitLab, GitHub Enterprise and Bitbucket, Gitpod automates the building of development environments on-premises, Efftinge said. It continuously monitors updates to any Git repository.
Gitpod will then configure the right tools for a specific git branch, automatically compile machine-executable code and download all the dependencies required to allow developers to build code on-premises. Rather than having to manually configure a desktop environment, developers can start coding in seconds, Efftinge said.
Gitpod borrows concepts from continuous integration platforms and applies them to development environments, he said, noting developers today typically spend multiple hours per week setting up and maintaining local developer environments.
By automating that process, he said, the local development environment can also better align with production environments. One of the reasons why code doesn’t work in a production environment when it is first deployed is because the local development environment has been manually configured in a way that doesn’t accurately reflect the production environment, Efftinge noted.
That issue becomes even more problematic when developers are working on multiple projects involving, for example, separate microservices that are all going to run in different production environments, he added.
Gitpod also prevents drift by making sure all versions of a local desktop environment among developer teams remain consistent. Collaboration also becomes easier when the members of the teams have standardized on the same instance of a local desktop environment.
Efftinge said there are already hundreds of thousands of developers using the Gitpod cloud service. The open source edition provides an option that will enable DevOps teams to self-host their own instance, he noted.
Gitpod, formerly TypeFox, collaborated with Google, Ericsson, Arm and Red Hat to develop the open source Eclipse Theia project, which provides a foundation for building IDEs in the cloud using TypeScript, CSS and HTML. Theia, now being advanced under the auspices of the Eclipse Foundation, consists of a front-end running in a browser or in the local desktop application and a back-end running on any host. Both the front-end and back-end communicate through JSON RPC over WebSockets. Gitpod leveraged that project to build its own cloud-based IDE.
In the wake of the COVID-19 pandemic, there’s naturally a lot more focus on automation and developer productivity. Most developers will be working from home for the foreseeable future to help combat the spread of the virus. Of course, most developers have been writing code outside the office for years. The challenge now is enabling teams of developers to develop applications as efficiently as possible regardless of where they are located. Eliminating inefficient manual tasks such as maintaining local development environments could be a significant step in that direction.
It’s not clear yet whether DevOps teams are more or less productive since the onslaught of the COVID-19 pandemic. However, it is apparent the need for a consistent experience among teams of highly distributed developers is acute.
Let’s get one thing out of the way. DevOps isn’t a panacea—it isn’t magic, it isn’t a requirement for any enterprise and it won’t work for every team in every situation. Above all, it isn’t a yardstick by which an outsider can measure great operations, development or IT. And if anybody tries to tell you it is, feel free to say thanks and politely change the subject. You’re the one responsible for delivering the services your business depends on, and if the way you do it meets the needs of your business and the team is happy, stick with it.
But if you’ve tried adopting DevOps methodology, it’s likely because your business needs to substantially alter itself to meet specific goals. And DevOps has demonstrated the ability to help many organizations. Unfortunately, just as many seem to abandon DevOps initiatives and roll back, sometimes more frustrated than if they hadn’t tried it in the first place.
IT might be the team responsible for reliability, but this is a big challenge in an increasingly “fail fast” era. Many businesses are encouraging their departments to experiment, learn from their mistakes and keep trying until they deliver business-transforming innovation. But in IT, the high visibility of issues—even those initially within the accepted risks of a new project—seem to be treated differently. Even minor and expected teething pains can be judged as failures in hindsight. And many of us have seen instances in which attempting something new and encountering difficulty seems to make it five times harder to get off the ground on the next attempt.
DevOps is a prime example. As its culture and practices gained popularity, companies were quick to jump on the bandwagon—only to stumble in the execution or not deliver anticipated “transformation” or measurable ROI. It’s not uncommon for these companies and decision-makers to be left with a bad taste in their mouths. They may be reluctant to revisit DevOps and try again, even with the gained value of previous investments and lessons learned.
This isn’t much of a surprise: Humans don’t like to investigate public failures, and everything in IT is public, assessed in binary absolutes. It either works or it doesn’t, apps are up or down, and everyone in the company can see them. It’s also natural for businesses to switch their focus to the next potential success if personal political capital was part of a DevOps project. And as engineers, looking forward is in our DNA. We’ve built our careers around finding new and better ways to meet customers’ needs, solving novel challenges, and permanently squashing nagging issues to make room for new technology. The trick is to avoid considering DevOps a passing fad.
There’s significant value to be gleaned from any investment in DevOps—a better understanding of the human dynamics of your organization, at a minimum. If your team tried to implement some of the processes of DevOps or took the advanced step of adopting DevOps culture, don’t forget you did it for a reason. Go back and review what led you to consider DevOps in the first place. Chances are the business needs behind it haven’t changed and may have even expanded.
Outline those earlier reasons—they’re likely still there, even under novel circumstances such as shifting the team to work from home. Did your DevOps effort meet its original objectives, regardless of any rear-view assessment? Drill into the details where it didn’t. Was it due to culture, communication, risk reassessment or operations challenges? Did your team end up building something different than what you intended—a compromise not meeting the business’s needs? Take your time; you likely had many good people on the effort who are eager to share what they learned. A previous misstep could be due to a skills gap, software, management support or something as basic as infrastructure. The first step in taking another swing at DevOps is analyzing the previous attempt with data instead of opinions.
And there’s a good reason you’re likely planning to try again: The stakes are high. According to Forrester, 80% of revenue growth will depend on digital offerings and operations by 2022. Organizations will survive and grow depending on their ability to design and deliver technology services, respond to issues and meet growing user expectations. At the same time, considering the environment brought on by COVID-19, IT teams are seeking new ways to sustain operations and use the time to build a head start for when business picks up.
You’ll need a deputy to help you conduct a forensic analysis and your QA team might be an unexpected place to find the right candidate. QA likes many of the outcomes of DevOps practices because they’re often suffering horror-show weekends at the hands of big-bang monolithic deployments at several companies. If you don’t find a detective there, empower someone who focuses on quality service and considers it a peer to availability, security and resiliency.
Your first job will be to demark the fault lines. Remember, the task isn’t to assign blame and a good admin-side manner is required to prevent this. Remind the team the mission is to avoid making the same mistakes, not to point fingers. Perhaps you originally had fantastic buy-in but everyone got caught up in the wrong details. Was the problem operational? You’ll need to know.
Second: Admit Mistakes and Ask for Feedback
Once you’ve conducted your analysis, you’re ready to take it to the next step: humanizing past technical actions. Consider what the previous attempt might have been like for different teams and people. Remember what it was like when you rode the help desk, when you were sitting in the data center on a weekend or when you were working as a dev lead under an impossible deadline. Chances are you’ll remember the common frustration was external direction not taking people into account. DevOps success is primarily about people. Align your DevOps reboot with the humans on your team and the processes will follow.
For instance, your company may have hired outside consultants to “rub a little DevOps on it,” and it’s possible they evangelized a lot of dogma. “Do exactly these things, this exact way, or you’ll fail at digital transformation,” they might have said. There may have even been FUD and frightening charts. Perhaps they said everything would be neatly wrapped up in six months and you’d achieve a high-performing, blended, and fully active nirvana within a year. “You could be the next Netflix!” You’ve probably heard this story several times by now, and if it’s happened to you, know you’re not alone.
But your approach this time will be different because it will be yours. You will have noted sharp edges needing to be filed down. The broader team will be integral to conversations from the get-go. Internal champions won’t be under the influence of ballyhoo, fancy decks or hard sells. Your team will have a list of concerns but also possibilities reflecting a shared interest in modernizing operations. One look at salaries for job postings with “DevOps” in the skill set has likely piqued more interest from your team than a year ago.
Open conversation has always been the hallmark of good forensic analysis. Express what you think went wrong the last time and encourage frankness. Acknowledge concerns—previous outcomes may have validated many of them. Your team will be looking for proof you’ve given thought to a process that might—in extreme circumstances—temporarily affect availability or lead to a security concern. Maintain an open invitation for everyone on the team to be a part of the conversation and hear their concerns. And wherever possible, lean toward person-to-person communication. You’re changing hearts and minds, not reviewing governance policy.
Third: Unite Your Team by Confronting Obstacles Together
Don’t perform a shotgun wedding between ops and dev. Administrators and developers are drawn to their technology foci for personal reasons and interests. One of the most cited reasons for unsuccessful DevOps plans is a directive to homogenize the team, followed by shock this didn’t work. Developers are attracted to and rewarded for innovation and building new things, while admins take pride in finding ways to migrate the mission-critical apps everyone forgets about onto new hosting platforms. They’re complementary, integrable engineers, but they’re not interchangeable cogs.
Contrary to popular opinion, telling developers they’re going to carry a pager for escalation doesn’t magically improve code quality and can slow innovation. They may even quit, even in this chaotic economy. And telling ops they need to learn code patterns, git merge and dev toolchains will be an unwelcome distraction not related to keeping their business running or meeting their personal review goals. They also may quit.
It might be helpful to share with your team the simple idea you embrace: Unfounded stories of friction between dev and ops aren’t about the teams. They’re usually someone else’s war story about the organization, technology or process obstacles dividing them. At its heart, DevOps is about clearing these obstacles, not replacing them with new ones.
By 2020, you’ve likely met someone from a team who had an opportunity to work based on tenets of DevOps, and they likely have no intention of going back. They’ll tell you they built or modified interaction models and evolved their deployment methodology organically. They streamlined the way code is built, improved testing at the bench level, staging and production. Even some companies needing to maintain specific waterfall processes for business or regulatory reasons may benefit if the transition is organic and incorporates their specific needs.
Fourth: Set Your Plan in Action
The last step—and this time, hopefully, the easiest—is to set your plan in motion, especially if you’re doing so at a smaller scale with better instrumentation than before. Ops teams and developers are people of action. We like to research, test and discover, but we’re happiest when our work sees production and we have a positive impact on the business. And often with initial forays into DevOps, stymied progress is what makes teams give up. By tracking ops and business metrics together, all the stakeholders will be able to share a sense of progress toward the overall goals, even when you break a few things along the way. Think of it as fail fast insurance.
For example, consider adding development metrics and business metrics alongside your traditional infrastructure data. Track rate of change, error rate over time, deployment events and PR requests to get a measure of release times. Share your application performance management (APM) metrics with the whole team—real-time user-to-app-code-to-infrastructure-to-resources data sparks insightful cross-team conversation. But you should also track metrics affected by ops quality, including visitor time on site, page abandons, service desk ticket rate and CSAT. You likely already have the data you need, but perhaps it’s siloed in different systems. If your dashboards combine data mirroring the mix of teams and infrastructure flying in formation, it’ll be much easier to identify issues, evolve your initial plan to suit your unique environment and improve overall DevOps collaboration.
And this time, you’ll be able to see code check-ins, unit tests, builds, pipeline progress, deployment to staging and prod, and follow-through on performance, issues and anomalies. If the team gets nervous trying something new, you’ll have actionable data, the production feedback loops developers crave and common charts everyone agrees on. It’ll be easier to know your DevOps effort is working and to keep pushing forward as you address unexpected challenges.
You’ll Know It When You See It
I made a joke in a talk once that DevOps is a lot like being in a relationship: You kind of fall into it. You learn about it, adopt some of its practices and enjoy the experience when it works. You don’t set out to “get in love” and likewise don’t set out to “get in DevOps.” Rather, you find yourself in a situation developed with experience over time, and you wake up one day and realize, “Hey, we’re a DevOps shop!” That’s why you can’t buy it in a box, and nobody else’s will be like yours. It’s not about the technology, it’s about the humans working together to manage it.
Maybe this is the best reason to give DevOps another shot. It didn’t spring from a consulting team as a framework to drive engagement or from a vendor with an appliance requiring admins to bend to arcane workflows. It came from people; from developers and administrators who fought the same operations challenges we all have and who wanted to share what they learned. And this is why, outside of a bit of time investment from your team, DevOps is free. It’s made to help, not to sell you anything.
Global businesses are in the midst of an enormous digital transformation wave. As we step into the realm of industry 4.0, exponential technologies are becoming a fundamental segment of traditional business settings.
Despite having access to transformative technologies, however, many organizations fail to embrace disruption and harness their potential to stay ahead of the curve. Much of this stems from their inability to foster a collaborative environment wherein myriad teams and operating IT systems work in unison to achieve their goals. Without a strong foundation of infrastructure automation and well-chosen team collaborations, embarking on the digital transformation journey is difficult. And to do that, adopting a DevOps mindset is necessary. In essence, organizations need to incorporate DevOps practices to transform, compete and protect their new value pools without sacrificing quality, stability and productivity.
Digital Transformation and DevOps
DevOps helps enterprises succeed with digital transformation by triggering a paradigm shift in the cultural mindset of the business, breaking down silos and driving continuous change and rapid experimentation.
There are multiple benefits of merging DevOps with a digital transformation strategy. First, this methodology breaks down the silos between IT and business operations, thereby ensuring consistent levels of productivity, efficiency and service delivery. This has a direct impact on companies’ time-to-market. Second, bug fixes are much easier due to the automation of toolchains. Third, the automation that DevOps introduces improves developer/IT productivity as they can focus more on innovation rather than being caught in a cycle of bug-fixing and firefighting.
Despite DevOps’ contribution to digital transformation, its adoption in many industries is still slow due mainly to scarcity of skills and the right toolset. Complete automation remains elusive. Additionally, patchy adoption has given rise to a two-paced overall technology environment—one part is fully integrated with DevOps and the other part is users still mulling over the “how” of tightly integrating it in the overall process.
Advanced technologies such as artificial intelligence and machine learning could resolve these issues. They can alleviate operational complexities in DevOps to help organizations transform at a faster pace. The following are some of the benefits offered by these technologies.
Better Automation
The need to rely on manual processes can be reduced with AI- and ML-based technologies, which has an enormous impact on data analysis. Organizations can use powerful AI data mapping techniques to automate data transformation processes with ease and speed. They can make use of the predictive ability to accelerate the process, increasing accuracy by leaps and bounds. This transformed data can be easily integrated using another solution AI integration, and so it becomes easier for users to work on data for extracting business intelligence and streamlining decision-making. This entire process takes only a few minutes to complete. Plus, since the need for manual intervention is curtailed, developers who previously were mired in handling transformation operations can move on to more strategic tasks such as governance, control and resource planning.
Better Security Through Intelligent Anomaly Detection
AI and ML-powered technologies, with their highly precise features, augment system security to deliver better performance. With a centralized logging architecture, users can record and root out suspicious activity on the network. These technologies togehter with DevOps can help mitigate the impact of threats and hacker attacks to help companies drive their digital transformation initiatives with precision.
Better Team Collaboration
In any organization, two teams function in parallel: the developer team, which has the responsibility to code fast, and the operations team, which ensures minimal disruption. While maintaining this balance can be difficult, transformative technologies such as AI and ML can help these two teams work in unison, improving collaboration by helping them have a single, unified view into system issues across the business ecosystem.
Better Customer Experience
AI-based technologies can have a direct impact on organizational productivity and performance. They can develop and launch their products faster (keeping customer expectations in mind) with lower TCO. Plus, DevOps-inspired service teams are able to provide a higher level of service, resulting in more satisfied customers
AI-powered technologies are critical to kickstart DevOps performance and ultimately drive digital transformation initiatives. Infusion of AI not only improves enabling faster development and deployment cycles through automation, but also enables better collaboration and uncovers and remediates key issues, helping businesses unlock digital transformation value.
Admitting things will go wrong isn’t easy for anyone or any team. But modern engineering practices have moved beyond this fear, giving birth to a new practice in DevOps and site reliability engineering (SRE) known as resilience engineering.
Resilience engineering today isn’t thought of as a function. However, just as DevOps was a description of culture before it was a role and site reliability was an extension of operations before it was a focus, I wouldn’t be surprised if resilience engineering became a function in the new future. The first question most will ask however is, “Isn’t this just SRE?” The purpose of the term is to change the focus from simply reacting to incidents to developing long-term response strategies for them.
Because the expectation in these environments is that things will break, resilience is the responsibility of existing DevOps and cloud operations teams. When applications and services do break, a “fly by the seat of your pants” response strategy will not work.
A Focus on Frameworks
Resilience engineering, while rooted in engineering practices, is largely focused on building strategies and a framework for their execution. This leaves the process of building resilience into a largely unestablished system in part because each system is unique. And, how you respond to issues in that system will likely be unique, even if the management plane that reports issues is not.
The job of resilience engineering is to:
Establish procedures, habits and decision trees
When things break, fight is the only option. Operators and on-call engineers need to address issues in a systematic and repeatable way and do their best to remove emotion and fear from the equation. This not only helps triage and resolve issues, but it also makes sure the activity associated with the issue leads to meaningful insights in post mortems and future collaboration. Part of that is establishing habits and decision-making processes for those who are on-call. The processes help prioritize what to focus on, help catch details because details are critical.
Be data-driven
Resilience engineering must rely on data. This is another place where traditional SRE practices grow with a focus on resilience. In typical SRE environments, the focus is on the now, using real-time dashboards of the current state. When you think about resilience you are thinking about the past’s impact on the future, not the now. The only way to do that is to make sure the data supports it; thus, part of resilience engineering is making sure the data is there. Instead of data silos that most organizations have across their delivery chain. Resilience engineering should ensure that telemetry across the entire delivery chain is captured, correlated and shared. The reason this is critical is that what happens early in the delivery chain directly impacts incidents. That activity can be the source of answers, it can be the triggers for rollback, or it can be the clarity needed to prevent similar issues in the future. Without continuity between each stage of the delivery chain, it’s easy to miss correlated events that can lead to more systemic problems.
Engineering out of reproducible incidents
For most, the best part of resilience engineering is taking what is learned from previous incidents and finding ways to automate future resolution. Learning from data and having consistency in habit leads to the ability to create runbooks and automate remediation for known issues. Often incident response audit trails can read like playbooks for addressing issues of a particular type. When the resolution is not directly related to code and the potential of issues to surface again in the future is inevitable, being able to build intelligence to address it saves waking someone up at midnight and much shorter impact on customers.
The Resilience Stack
Organizations looking to embrace resilience engineering need to have a toolkit built for it. It’s pretty straightforward but worth highlighting. The resilience stack will include:
Observability and/or monitoring tool.
Incident response tool.
On-call strategy documentation.
Post mortem process and documentation.
Documented processes including recommend response steps.
Path to automation.
For those with a relatively mature and automated environment, the next step is chaos engineering—embracing chaos as a way to get ahead of incidents before they happen in the wild.
Get your markdown skills to maximum level. There is a lot of documenting that needs to happen with comprehensive resilience engineering. But these documents should not be shelf-ware—they should be living and ultimately lead to the implementation of automation or feedback to development.
As for monitoring, observability and incident response tools, it’s not enough to simply implement them. Knowing how data will be collected, consumed and actualized is also necessary. So is establishing an on-call strategy with purpose, not just because having everyone on-call is the “cool thing to do.”
It may seem obvious to say that organizations want system resiliency. What is not obvious is how to execute it. When organizations see the gaps (and are often embarrassed by them), they understand that resilience is a focus for either current functions or new ones in the future. That is why it’s worthwhile to talk about resilience engineering and what makes it effective.
Spotify has entered the next phase of the open source Backstage catalog project by adding support for templates through which the process of deploying software components now can be automated.
Backstage was developed by Spotify to create an open source catalog through which DevOps teams could build portals through which developer tools are centrally managed.
Stefan Ålund, platform developer experience product lead for Spotify, said the goal is to bring some order to what otherwise would be a chaotic IT environment. By standardizing the tools made available to developers, Backstage enables IT organizations to develop more consistent workflow processes, he noted.
Ålund said DevOps teams via custom templates can automate those workflows to the point where a microservice, website or other software component can be deployed via a single click. That approach also serves to encourage reuse of both developer tools and the modules those tools were used to create, he said.
In some instances, those templates will eliminate the need to depend on site reliability engineers (SREs) to deploy the same code over and over, he added.
Spotify is currently proposing to make Backstage a sandbox-level project that would be further developed under the auspices of the Cloud Native Computing Foundation (CNCF).
In the meantime, Alund said Spotify will continue to refine a service catalog that has been widely employed across DevOps teams for the past four years on top of a core instance of the open source Jenkins continuous integration/continuous deployment (CI/CD) platform.
It’s not clear how DevOps-mature an organization must be to realize the need for a catalog through which modules of code could more easily be reused. In some cases, the transition to microservices may inevitably force the issue. Rather than having developers potentially reinventing the microservices wheel, a portal would make it easier to discover what software assets already exist and deploy them automatically.
A catalog also provides the added benefit of making it easier to track the provenance of a project as well as who currently has operational responsibility for it within the context of a larger software supply chain enabled by best DevOps practices, Alund noted.
Regardless of the level of DevOps maturity inside an organization, the need for a catalog to track services quickly becomes apparent as the number of microservices developed increases. It’s said that every company is now a software company. If software is to be managed as a digital business asset, then it’s critical for organizations to determine what modules of code they have and then determine which modules are the most valuable to the organization.
Only then can every company that aspires to be a provider of software that happens to manufacture something or provide a service be managed like a true software company. Anything short of that goal is just a mere statement of aspiration.
