staging-devopsy.kinsta.cloud

Category: Features

  • Ambassador Insights: Cloud-Native

    Ambassador Insights: Cloud-Native

    Cloud-native is a methodology and a mindset that’s been gaining traction in the DevOps and application development space as more organizations look to leverage the benefits of cloud infrastructure, including scalability. As with many other topics in the DevOps space, however, cloud-native isn’t easily definable; rather, it is loosely described by the technologies it utilizes, including containers and Kubernetes.

    In our second episode of Ambassador Insights, featuring DevOps Institute ambassadors Leonardo Murillo, CTO of Qwinix Technologies; Tracy Bannon, senior principal and DevOps strategic advisor and software architect at MITRE; and Pawel Piwosz, lead system engineer at EPAM Systems, we delve into what it means to be cloud-native, look at some of the cloud-native technologies helping shape the landscape and address the security aspects of cloud-native applications and infrastructures.

    The video is below, followed by a transcript of our conversation. Enjoy!

    Transcript

    Charlene O’Hanlon: Welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I am here with another episode of the DevOps Institute Ambassador Insights Panel Discussion. I’m so excited to have these on a monthly basis with some very, very smart people who also happen to be ambassadors with the DevOps Institute. And each month, we have a different topic of discussion to align with our monthly spotlight topics on staging-devopsy.kinsta.cloud.

    This month, we are going to be talking about cloud-native and cloud-native technologies, and so, I have some experts in the field right now. First up, we have Leonardo Murillo, who is the CTO of Qwinix Technologies. Hey, Leonardo, thank you so much for joining me today.

    Leonardo Murillo: Thank you for having me, Charlene. I really appreciate it. This is great.

    O’Hanlon: Alright, alright. Next up, we have Tracy Bannon, who is the Senior Principal and DevOps Strategic Advisor and Software Architect at MITRE. Tracy, thanks so much for joining me, we really appreciate it.

    Tracy Bannon: Thanks for the invite.

    O’Hanlon: Great. And finally, last but not least, we have Pawel Piwosz, who is the Lead System Engineer at EPAM Systems. Pawel, thank you, also, for joining me today, we really appreciate it.

    Pawel Piwosz: It’s a pleasure to be here with you.

    O’Hanlon: Great, great, great. So, let’s dive right into the discussion. I know we’ve been talking on staging-devopsy.kinsta.cloud and Container Journal a lot about cloud-native, but I’m not sure, actually, that a lot of people understand exactly what we mean when we say cloud-native, so maybe we should set the stage, if you will.

    Leonardo, maybe you can start us out since you are really focused heavily on cloud-native. Can you kinda tell us what we mean when we say cloud-native? What are we talking about?

    Murillo: Sure. So, I think when we talk about cloud-native, we’re talking about a specific mindset and patterns to apply when we’re building both systems as well as organizations, which is kinda one of the things that I wanted to discuss today, right? Because cloud-native is not just how you build technology, and you don’t really need the cloud to build cloud-natively, right? Usually, when you think in terms of cloud-nativeness, you’re thinking about loosely coupled architecture, you’re thinking about containerization, immutability, statelessness, right? All of these are components that are incorporated in a cloud-native solution, and I think the organization has also to become cloud-native, and that’s where DevOps becomes really important, right? To be able to leverage and really take advantage of all the different qualities, right, that the cloud has basically surfaced and made available, right? What do you think, Tracy?

    Bannon: To extend on that and sort of foot stomp for what you’ve said already and love that you want to talk about the organization, we can talk about, I call it a reverse Conway maneuver.

    Murillo: Right. [Laughter]

    Bannon: [Laughter] So, there’s a lot to be said—I’m actually finding that there’s not agreement on what cloud-native is. There’s an argument—it means containers. Well, yes, and let’s talk about serverless and the impact of serverless. So, it’s not a specific architecture pattern, but it does mean that we are building to take the best advantage of the infinite scalability, right, and the self-healing nature and other aspects of cloud. Love your point as well, Leonardo—while we say it needs to be on cloud proper, building for cloud, right, doesn’t mean that I’m necessarily hosting in an AWS GCP, et cetera and so on. It means that I have applied those principles, and I can do that within my data center, my private cloud, or whether I’m paying somebody else to be the host for me.

    Murillo: Yeah, great point.

    Piwosz: That’s true, and it’s not only about the application, it’s about everything what is around. For example, CI/CD, how we store our code, how we approach to the code, how we approach the security networking. Because this is something that we very often forget when we are going to the cloud, right?

    O’Hanlon: Mm-hmm.

    Piwosz: So, platform as a service, we have everything, we don’t need experts.

    Bannon: [Laughter] Don’t get me started at all!

    O’Hanlon: [Laughter]

    Bannon: But that’s an interesting point is that there are so many fantastic capabilities that are being provided as a service that I don’t think the folks actually know where to begin. I’ve had some awesome infrastructure folks who go out and they do some Googling and they do some research and they come up with a reference architecture. And heaven forbid, but God love them, they go out and spin it up and push the button, and—wow, this is a good solution for my firm or for my client or for my needs—and it isn’t, necessarily.

    So, there’s a lot of trade space that we’re unintentionally losing with the rapidity that we’re moving, trying to move towards cloud. Architecture should be more important, not less important. It shouldn’t be a stalling factor up front, but I jokingly say that, in order to push some value, provide value out into industry or to my clients, I have to be doing that from vision forward, right? I can’t take a steel girder and put it through a wood chipper, right? It’s not going to work because it wasn’t constructed and thought of that way.

    But Leonardo, to your point earlier, as much as the technology to me is the fun and sexy part, the human aspect really needs to be dealt with as well. We talk about it a lot in the DevOps piece of it, the DevOps portion or support effort on it, but you really bring up that cloud-native requires us to think about the organizational structure and building a separate culture than what we’ve had before. I’d be interested in what you think about some of the emerging software factories, or should I say continued proliferation of software factories as the way to move forward on software?

    Murillo: I think that actually talks about kind of a different subject, and I’d like to kinda step back a little and think—because you mentioned something that is very much aligned to this, and it is the whole strategy as to how you approach the cloud, right? It’s not just about click a button and going in, right?

    Bannon: Mm-hmm.

    Murillo: And, to me, that has a lot of resonance to what DevOps is all about, right? If you think into kinda the cada mindset, right, define your North Star first, right, assess your current state, think about it consciously and mindfully, right?

    I think if organizations that are looking to go into the cloud or mature into the cloud do take that step, do take time, they will be able to maneuver this gigantic ecosystem of tools that are out there and technologies that are out there. Because I think there’s also an interesting component that we should discuss. You mentioned, Tracy, how it’s not just about the technology, it’s also about the humans, right, the people that are implementing.

    Bannon: Mm-hmm.

    Murillo: But I think that also resonates with the fact that technology is not there just for the sake of picking the latest and greatest tool, right? I read this great post by somebody that I can’t recall, that basically talked about how boring is good. You know, how boring technology is good because people are used to it and they’re kinda like aware of how it works.

    And I think the closer you are in your evolution path to what is comfortable, the better. And I think that’s one of the problems that I sometimes see in cloud adoption—people try to bite too big of a chunk of change at a given time, right?

    Bannon: Yep. Mm-hmm.

    Murillo: And there’s so much to choose from to make that huge bite. An actually targeted approach that is mindfully defined that is well strategized will solve a lot of these problems, right? Because it will give you a signal amongst all this ecosystem noise that teams are gonna be exposed to, right? So, Pawel, you are kinda like engineering these solutions, right? How do you work around this ultra-diversity of available technologies, right, when you’re building something?

    Piwosz: Mm-hmm. This is … a very big problem. Because right now, together with cloud, we gained much, much more speed with everything, really. So, imagine 20 years ago you had a server room with racks and servers there, so you’d change only the server, but the logical side was still the same.

    Today, we are jumping. Let’s stay with AWS. We are jumping from instituting analysis to microservices, then to serverless microservices, then to serverless itself. Who knows what we will find next year, for example, right? You need to switch your mindset here. This is something that especially all kinds of CisOps—well, I am all kinds of CisOps—people have in mind, right? The same for networking, for security. There is a huge difference in speed here.

    So, you need to incorporate into your mind things like do fast, fail fast, learn fast—especially learn fast, because we are forgetting about this very often; too often, I would say. And also, we are forgetting very often in the trenches about the security of the cloud.

    Bannon: Oh, gosh, yes.

    Piwosz: Because—yes, because we’re saying, okay, we have a shared responsibility model, so they are responsible for everything. We’re just running our application and not caring about anything else, what is really, really wrong, I believe.

    Murillo: And I think that points to a fundamental misunderstanding, right, of what security in the context of cloud native architecture is all about, right? And I also think about, Tracy mentioned this infinite capacity, right? And you mentioned, Pawel, going fast.

    I’ve been thinking a lot recently as to how those two components need also to be very effectively managed.

    Bannon: Yes.

    Murillo: By leadership, by those that are sponsoring these initiatives, right? Because after all—and this is something that I’ve been talking about lately, right? We have optimized for speed alone already without having, really, awareness of the impact that that would have on the environment and many things, right? And I think we really need to establish a mindset where engineering teams are aware that infinite capacity doesn’t mean just free for all, grab whatever amount of resources you have, that shared response security is not infinite, overwhelming security, right?

    And I think this is also relevant in the context of the tooling that we were talking about, right? Everything now is available kinda point and click. You download a package, you have an appointment. You download another package, you have authentication and connectivity, right? And we don’t go into details necessary to understand kinda the supply chain of all these solutions.

    So, I think that’s where—the mindset of DevOps, right, reduce waste also becomes very relevant, right? Just because you have infinite capacity doesn’t mean you can’t be wasteful or you don’t have to be constantly evaluating the outcome of your ongoing efforts, right? Yeah, so, I think that’s very important.

    Bannon: There’s a treasure trove of topics that you just landed on, so it sounds like it could be a longer collaborative.

    O’Hanlon: Yeah, right. [Laughter]

    Bannon: So, in terms of reducing waste, one of the things that I’ll put out there is that I believe, in what I’ve observed with teams that I run or teams that I’m reviewing the content is that some of the cloud capabilities have made us, I think, lesser programmers, lesser developers, because we’re not concerned about the same things that we were before. We’ve delegated authority or we’ve delegated that concern.

    I’ve seen some pretty hideous, performance-wise, if I were to run it anywhere other than being able to up my compute, it used to be that we had to be concerned because it cost a lot to add additional resources, right? If it wasn’t as performant as we needed it to be, you just threw more hardware at it. That went away for a long time because it was cost-prohibitive.

    We’ve almost gone back and revisited that in some ways. From a security perspective, it’s always been my perspective that it needs to be baked in. It has to be part of the ecosystem. So, when folks started talking about DevSecOps, I was actually against that, because DevOps means that there’s a security part of it, but I do understand that it was, at times, not thought about. Our developers need to be educated, but they need to be held accountable because it becomes—there is a group effort. Now, when I say developers, I mean the athletes who are hands-on, they’re engineering with us, they’re moving the software forward.

    But there are two pieces that come to mind with this. There’s a limit to how much they can consume. Mentally, there’s a limit to how much they consume. I’m looking at Pawel’s background and I’m thinking to myself, “I love all the stickers” and yet, those are all the technologies that he’s considering that he’s looking at. So, as leaders in technology, one of the things that we need to do is to provide guidance to the folks who are on our teams to help them reduce the noise. It doesn’t mean to ignore the new things, but it does mean go ahead and get to finish, get to done on one thing, get it working, learn from it, and then improve it. And if improving it means that there’s a certain amount of acceptable refactoring or pulling in another tool—absolutely, right? That’s technology insertion, that’s a good, smart thing.

    But it does also mean that we don’t instantly glom onto everything that’s coming along. I have one organization in particular where every team is allowed to have the autonomy and latitude and I’m just there as an observer, and it’s a little bit of melee. There are lots of good pockets of interesting things, but because there’s such technical diversity even in a small space, they’re having a hard time, because they’re not able to get crisp and good and deliberate with the first set of tools. To your point earlier, Pawel, they’re not getting good enough with what they’re doing before they’re switching on to something else.

    So, cloud native mindset is pretty important, but helping to folks understand cloud native from a, what is it from a patterns perspective, what are the architectural tradeoffs for it, and then helping them to make selections and stick with it long enough to get a success, I think, are really keys to helping organizations.

    O’Hanlon: So, do you guys think that cloud-native is kind of an all-or-nothing proposition? Are organizations—have you seen organizations kind of going all-in on cloud-native and then maybe pull back?

    Murillo: I’ve seen them going all in and I’ve seen them crash and burn. [Laughter]

    Bannon: Yes! [Laughter] Alright, then!

    Murillo: Yeah, I think—I was talking the other day as to, everybody knows juggling is really good for the brain, but if you try to learn to juggle with your most precious items, you’ll never learn because you’re gonna be very afraid.

    I think it’s the same about cloud and DevOps, right? Everybody knows it’s great, everybody knows there’s gonna be a lot of value out of it, but if you try to learn it with your most precious things—for instance, your entire organization—you’re gonna have a lot of resistance to getting it right.

    So, I think the same applies for DevOps and cloud-native. I think you need to iterate. You need to start small with projects that you’re capable of experimenting with, right? Kinda like the whole concept of a culture of experimentation and iteration is important, right? But there’s gotta be awareness to the fact that you cannot just experiment with everything, right, or with everything at the same time.

    So, what I mentioned, right, bite small pieces at a time, iterate, do concepts, and use those concepts to build kinda your operating model, right? What does a cloud mean to you for your organization, right? And then expand up until you have a very solid framework that is well establish, well understood, and then you can kinda start juggling with fire, but not until then.

    Bannon: That also helps us think through greenfield versus brownfield. I deal a lot with governments and a lot with federal governments and different agencies in defense. And there’s a tremendous amount of brownfield. It doesn’t mean that there’s old brownfield, but it means that there’s something pre-existing, so there have to be decisions made about where do I add on the cloud-native? Do I do it around the edges, is it incremental, am I doing strangler fig tree patterns, et cetera and so on? That’s one piece of it. Net new sometimes is a good place to try cloud-native, right, because you do have perhaps less confines around it, so take something smaller that’s greenfield and make your first foray that way.

    I think it’s an interesting conversation about the starting and stopping points for cloud-native? I noticed—and I’d like to hear, Pawel, if you’ve seen the same thing—I saw everybody lift and shift as quickly as they could. “I wanna get rid of my data center, so I’m just gonna move my workloads, right? IAS, I’m gonna move my workloads.”

    So, they moved their workloads, and I naturally thought the progression would be to pass or would be to cloud-native and to the refactoring. What I actually observed was a pendulum swing to the analytics side. And so, there was a tremendous, I have all of this compute available to me, I have less expensive storage, I’ll move over to the analytics side, and we’re just starting to see, a real increase in the cloud-native application space. Unless you’re truly talking about upstarts and greenfielding, there has been much less of it with the brownfield and the incremental improvements.

    Piwosz: Yeah, I agree with you. So, first of all, if you just do lift and shift to cloud, whatever we call the cloud, you will cry very soon. So, this is the first thing.

    The second—yes, we have a lot of possibilities regarding analytics, we have beautiful words right now, buzzwords like observability, telemetry, et cetera, et cetera. So, we’re just expanding our monitoring, let’s say old-fashioned monitoring to the new areas and collect more and more and more, and more structured things.

    So, this is something what is very, very easily achievable, but also—and this is in relation to the previous topic here, if you start with cloud, well, you are already in the cloud. There should be still a logic behind everything. Because, today is so tempting, because you do not have to do the initial investment, right? You just click a button and start using serverless or just create a big, big cluster of something, right?

    And then, in my work, I observe this multiple times, then you create a crazy, really crazy solution for a very simple thing. Well, what can go wrong in this, right? So you are using like 10 or more technologies which are completely different, you are trying to wire them together and then you are saying—okay, I know 20 technologies, it looks perfectly well in my CV. But when you talk with people, you just realize that it doesn’t work as it should work, really. That’s why, very often, organizations which are going to cloud and do not take logic in this, how it is organized, how it is architected, how this even developed, they are paying much, much more, not just because they did lift and shift, but they started to create very, very crazy solutions, right? And this is the kind of waste that you mentioned as well.

    Bannon: I’m gonna throw out just a couple quick words that’ll make people cringe, but when I think about—so, agility 20 years ago, right, the agile manifesto, there’s a woman named Linda Northrop from the Software Engineering Institute at Carnegie Mellon who said it was one of the worst things that ever happened to software architecture, because unintentionally, there was this emergent architecture, my architectures will just emerge, I don’t have to worry about them in advance. I want to push forward that enterprise architecture needs to still exist, but in a different form, in a different format. There still needs to be, it’s okay for there to be somebody more senior, somebody who is helping to drive the architecture and helping to pick which cloud technologies and where cloud native is the most appropriate.

    Because there’s different trade space, right? Even if I talk containers, there’s different trade spaces between how I’m using the containers and how I’m moving forward with that. Does that resonate with you, Pawel and Leonardo?

    Piwosz: Yes, yes. I would even add here that if you want to be cloud-native, your developers need to be cloud-native. So, there is no more, “It works on my machine”—this is obvious, right? But also, I will be bold here, so even development should go into cloud. And this is another layer here, which we didn’t touch, but it is very important, I believe.

    O’Hanlon: Well, I feel like we could have this conversation for at least another hour, but unfortunately, we gotta wrap things up, guys. But I do appreciate Tracy and Pawel and Leonardo for your insights. You guys are great. I’m gonna have all three of you back on and we’ll talk about other things in the future. We have lots of topics to get through this year.

    The level of intelligence and insight you guys bring to these conversations is just so, so value added, so I do appreciate your time in joining me today for another one of our DevOps Institute Ambassadors Panel Discussions. So, thank you, guys, again. We really do appreciate it, and please do stay in touch with me. I’d really absolutely love to get your expertise back on the show, so.

    Bannon: Alright, fantastic. Be well. Stay safe, everybody.

    Murillo: Thank you very much.

    Piwosz: Thanks, everybody. Thank you.

  • Amex, Adobe Join GitHub Intern Program

    Amex, Adobe Join GitHub Intern Program

    GitHub revealed today that Adobe and American Express have joined its Summer 2021 Fellowship program, a 12-week, hands-on curriculum where interns work alongside developers to contribute to open source projects hosted on the GitHub repository.

    Vanessa Gennarelli, senior director of education at GitHub, said the overall goal of the program is increase the pool of developer talent with experience working remotely on an open source project that requires a fair amount of collaboration with other developers.

    The program was developed in collaboration with Major League Hacking (MLH), which organizes hackathons for students. Each intern participates in a series of short hackathon sprints involving multiple open source projects over the 12-week period. GitHub originally created the fellowship program as a way to address the demand for online internships during the COVID-19 pandemic.

    Those internships have provided open source maintainers with access to a pool of talent that can reside anywhere versus, for example, always trying to recruit individuals located in a specific geographic area, Gennarelli said. GitHub is also trying to increase diversity within the open source community, Gennarelli added.

    Three quarters of open source maintainers (76%) that have worked with MLH interns reported their open source project was in a better state after working with MLH Fellows. Of eligible fellows who were matched for jobs with an MLH Fellowship partner company, more than 20% ended up receiving full-time offers at that company.

    Mike Swift, MLH CEO, said the internships provide a way to partially close a gap in developer expertise that only continues to widen. Organizations are especially keen to find developers that have open source expertise, Swift added.

    A survey of 3,400 developers and technology managers conducted O’Reilly Media on behalf of IBM finds 65% of respondents preferred skills related to the underlying open source technologies. The same percentage agreed that contributions to open source projects impress potential employers and result in better professional opportunities. In many cases, open source projects are among some of the most innovative development initiatives in the IT industry, Swift noted.

    Of course, as open source becomes a primary driver for building software, more contributors are looking to get paid for their efforts. Much of that compensation comes in the form of organizations that hire developers for the express purpose of contributing to open source projects that they deem critical to their operations.

    Regardless of how developers are compensated for their time and effort, it is apparent open source projects are the fountainhead from which many opportunities spring. Future success in any endeavor has as much to do with who someone knows as it does actual talent. The best place for any developer to expand their base of industry contact is to collaborate on an open source project. The more projects they contribute to, the greater the reach of their personal network and, by extension, their net worth, will become.

  • DevSecOps May Be Key to Prevent Data Leaks

    DevSecOps May Be Key to Prevent Data Leaks

    Data leakage has become something of a norm in the digital realm, despite the fact that cybersecurity budgets are growing and more engineers are assigned to these very issues. Nowhere does this seem more true than in the realm of health care, where breaches that expose sensitive patient data are, sadly, a fairly common occurrence. 

    A recent report by Approov illustrates how severe the problem has become. According to Approov’s  All That We Let In research report, many of the mobile healthcare applications in use today are leaking sensitive patient data through APIs, potentially compromising millions of patients. 

    The study tested 30 popular mobile health (mHealth) apps, and the research estimates that some 23 million mHealth users are exposed, at a minimum. The average number of downloads for each app tested was 772,619. Analysts expect that the total number of users exposed by the 318,000 mHealth apps now available on major app stores is likely far greater. Among vulnerabilities detailed in the report:

    • 50% of the records accessed contained names, Social Security numbers, addresses, birthdates, allergies, medications and other sensitive data for patients.
    • 50% of the APIs tested allowed users (medical professionals) to access the pathology, x-rays and clinical results of other patients.
    • 50% of the APIs tested did not authenticate requests with tokens.
    • Of the 30 popular apps tested, 77% contained hardcoded API keys, some of which don’t expire, and 7% contained hardcoded usernames and passwords. Seven percent of the API keys belonged to third-party payment processors that warn against hard-coding their secret keys in plain text.

    “Look, let’s point out the pink elephant out in the room,” said Alissa Knight, researcher and author of the report. “There will always be vulnerabilities in code, so long as humans are writing it. Humans are fallible. But, I didn’t expect to find every app I tested would have hard-coded keys and tokens, and all of the APIs to be vulnerable to broken object-level authorization (BOLA) vulnerabilities allowing me to access patient reports, X-rays, pathology reports and full PHI records in their database. The problem is clearly systemic.”

    The report helps to illustrate a critical point: Sloppy code can lead to data leakage. “These findings are disappointing, but not at all surprising. The fact is, leading developers and their corporate and organizational customers consistently fail to recognize that APIs servicing remote clients, such as mobile apps, need a new and dedicated security paradigm,” said Approov founder and CEO David Stewart. “Because so few organizations deploy protections for APIs – that ensure only genuine mobile app instances can connect to backend servers – these APIs are an open door for threat actors, and present a real nightmare for vulnerable organizations and their patients.” 

    For organizations deploying apps using a DevOps methodology, it becomes very clear that much more must be done on the cybersecurity side to prevent data leakage. However, the general consensus is that data protection falls under the purview of CISOs and cybersecurity teams in the enterprise. Perhaps there is no better argument for adopting DevSecOps than the data leakage problems caused by insecure code and sloppy APIs. The report echoes that sentiment and offers several recommendations for developers creating and organizations using mobile applications. In other words, organizations should take several key steps to protect their customer data and sensitive resources, including:

    •  Address both app security and API security: Recognize that synthetic traffic to the API is an issue, and arises from bots and automated tools, not from genuine apps and legitimate data requests.
    • Shift left and shield right: Secure the development process and harden apps, but ensure that runtime protection is also in place.
    • Protect against X-in the middle attacks: Certificate pinning is critical, but often left undone because expired certificates can block apps and impact customer experience. However, when done correctly, certificate pinning does not impact either performance or availability.
    • Improve visibility into controls: Organizations and developers need to monitor the effectiveness of the controls they implement and adjust them easily – both for compliance with legislative mandates and to sustain data security and privacy.
    • Continuous testing: Penetration testing and static and dynamic code analysis should be performed regularly.

    Interestingly, those recommendations fit squarely into the role that DevSecOps should take in the DevOps process. 

  • Grafana Labs Adds On-Premises Observability Platform

    Grafana Labs Adds On-Premises Observability Platform

    Grafana Labs announced today the availability of a unified Grafana Enterprise Stack that enables IT teams to deploy a curated observability platform, based on open source tools such as Prometheus, in their own on-premises IT environment.

    Tom Wilkie, vice president of product for Grafana Labs, said Grafana Enterprise Stack, in addition to providing a version of Prometheus optimized for distributed computing environments, includes curated instances of open source Grafana dashboards, Loki log aggregation tools and the Cortex query engine.

    Grafana Enterprise Stack also includes plugins for visualizing data from other commercial tools in Grafana, such as Splunk, New Relic, MongoDB, ServiceNow, Oracle and Snowflake. In addition, it includes reporting tools and enhanced authentication and security controls.

    Grafana Labs

    Developed under the auspices of the Cloud Native Computing Foundation (CNCF), Prometheus has gained traction as a monitoring platform used primarily in Kubernetes environments. However, Wilkie said it’s only a matter of time before IT organizations expand their use of Prometheus to include a wider range of platforms. The Grafana Enterprise Stack facilitates that transition by making it easier for organizations to deploy a complete observability platform based on open source software, said Wilkie.

    While open source software has a key role to play in enabling observability, most IT organizations today rely on a range of proprietary tools to monitor IT environments. Many of those tools will be replaced, in the months ahead, by observability platforms that provide more context than individual monitoring tools currently do. However, it’s not clear yet if IT teams will prefer open source or proprietary platforms that, in most cases, incorporate open source components.

    As IT environments become more complex, the tools most organizations rely on today don’t surface enough actionable insights. Most IT teams today still waste a fair amount of time navigating amongst multiple tools in an effort to discover the root cause of a problem. It’s not uncommon for IT teams to take days to discover the source of a problem that is then fixed in a few minutes. The expectation is that observability platforms will sharply reduce the amount of time and effort required to investigate, for example, a performance issue.

    Of course, to achieve that goal, applications themselves will need to become more instrumented. A mix of open source and proprietary agent software will make it easier to collect traces, logs and other metrics at a reduced cost. In many cases, IT teams have been reluctant to fully instrument an IT environment, because of both the cost of proprietary agent software and the inherent challenges associated with deploying and managing it across an extended enterprise. However, as the deployment process for agent software becomes more automated, organizations are finding it easier to instrument their applications.

    It may be awhile before IT environments are fully instrumented. However, as it becomes easier to collect traces, logs and metrics, the level of observability that can be achieved across an enterprise will undoubtedly increase. The challenge and the opportunity then becomes employing the greater visibility provided by these platforms to manage the sprawl of applications and platforms across IT more proactively.

  • DevSecOps Implementation: Patch Management

    DevSecOps Implementation: Patch Management

    Patch management has been a thorn in IT’s side for decades. While it is undeniably necessary for security and stability purposes, the staggering array of patches that are available make managing them effectively nearly a full-time job – or a job better left to users. Few IT professionals want to be the “patch person,” and yet, nearly all IT professionals want their systems protected by the latest patches. No one wants to find out an intrusion was easily preventable via patching. It goes without saying that the SolarWinds attack has left quite a few IT departments scrambling for an alternate solution.

    The world of patch management has gone through several evolutions that we won’t cover in much detail here. Instead, we’ll focus on what’s available, what you should look for and where the market is headed. Suffice it to say that patch management as a practice has grown from an individual applying patches to servers and server apps while employees were encouraged to patch their equipment, to complex systems that manage the patching themselves, with IT oversight. Currently, patch management is often bundled with endpoint management, simply because many of the patches are going to end points (user machines and devices).

    Out of this growth have come several market differentiators that you should be aware of when looking into a way to manage the avalanche of updates the average organization is seeing.

    • Centralized or de-centralized? Increasingly, patch management is run on servers/cloud and pushes changes out to those machines/devices that need them, or agents on each machine manage updating themselves. Which is best for a given organization really varies. If a lot of machines are running at the edge of their capability, an agent running updates in the background might be too much to ask. In that scenario, a server-managed install environment is probably better. Conversely, if a centralized location to run updates from is considered an architectural weakness (because it requires access to the update pushing engine), agents might be the better plan.
    • OS support. We’re way past the days when single-OS solutions were considered useful. List the operating systems used in your environment, and choose a product accordingly. Most products on the market support Windows/Mac/Linux, but there are variances. First off, make certain your chosen product supports all three. Then ask, “Which flavors of Linux?” Make certain the flavors running in-house are supported by the software.
    • App support. There are a lot of applications out there. Which are supported by the tool? How much leeway does the customer have for adding applications by pointing the tool at update locations? Does it support FOSS updates? There are a lot of those too, and which ones matter. Make certain the tools the organization uses are supported or can be added.
    • Many tools will scan machines for update issues. Understand what your chosen tools scan for, and how the scans impact performance on the target machines.
    • Updates are not 100% perfect. There will inevitably be problems. Make certain the tool can roll back changes. Updating 50 core infrastructure machines, only to find, hours or days later, that the update breaks something demands roll-back capability.
    • Inter-relationships. Updating a piece of software can require that another piece of software or a driver be updated, which can demand that UEFI/BIOS be updated. Or the CMOS on a RAID controller. Understand how cascading updates are handled by the tool, and if the cascading updates can be packaged, so that a failure automatically rolls back the updates applied thus far.
    • Approvals. Speaking of driver and BIOS updates, what tools are available to allow a human to approve changes? No one wants willy-nilly updates to the drivers on core systems – or even to drivers on user systems.
    • Security of the tool itself. We’re in perilous times where IT security is concerned, and frankly, an update command-and-control server is an attacker’s dream machine – take it over, put your back-door update into the mix, and tell it to update every machine it manages. It cannot be understated: an update management tool must be as protected as possible – both by the customer locking down the installation and by the developer making sure the code is solid.

    Once the system is chosen and worked into your DevSecOps environment, updates will be more responsive, which leaves one more thing to consider – does it feed into your agile tools? If the update management tool notifies a project management tool like JIRA when it updates a server, then if code on the server breaks, the developers aren’t in the dark about changes, and will have breadcrumbs to help them track down the source of the problem.

    Imagine if manual updates became a rarity instead of the norm. There is a cost associated with this process, but most of the products on the market can be had for a reasonable price – if you waste a couple hours a month (or for some products, a year) on updating, they’re paying for themselves. Of course, your time is a sunk cost, and the cost of these is an operational cost, so there is an evaluation your organization will have to undertake. Given how busy everyone in DevOps and DevSecOps is, it is likely worth the investment for all but over-staffed organizations. What? There are a few!

    Find what suits your organization, and put it to use. Faster updates, less time investment. The idea is sound, you just need to figure out what suits your needs. And keep rocking it. You are managing updates already, this is just a way to make your life easier. And we could all use a bit of easier in a busy, complex IT environment.

  • Survey: Fixing Bugs Stealing Time from Development

    Survey: Fixing Bugs Stealing Time from Development

    A global survey of 950 developers published today finds more than a third (38%) of developers spend up to a quarter of their time fixing software bugs, with slightly more than a quarter (26%) spending up to half their time fixing bugs.

    Conducted by the market research firm Propeller Insights on behalf of Rollbar, a provider of artificial intelligence (AI) tools to detect software errors, the report also notes that 88% of developers find traditional error monitoring tools are not meeting expectations.

    Daniel Day, vice president of marketing at Rollbar, said the survey makes it apparent that continuing to rely on manual processes to surface errors in code is having a major downstream impact on both DevOps teams, in particular, and the business as a whole.

    For example, nearly nine in 10 developers (89%) also noted that undetected errors take a big toll on the business. More than one-fourth (26%) of developers also said that their employers have lost a significant number of users due to errors in software. The same share (26%) said software errors damage their company’s reputation and its ability to attract investments, and nearly a fifth (18%) said that undetected software problems anger their company’s investors.

    Nearly a third (32%) of developers said they spend up to 10 hours a week fixing bugs instead of writing code, while 16% said they spend up to 15 hours a week. Another 6% said they have to dedicate up to 20 hours a week fixing bugs instead of writing code.

    More than half of developers (55%) said that if they didn’t have to spend so much time fixing bugs, they would have the time to build new features and functionality. Many of these errors are not addressed because current tools require them to manually respond to errors (39%); it takes too long to find all of the details they need to fix bugs and errors (36%); focus on system stability and not enough on code health (31%); make it difficult to detect errors (29%); and have an approach to error aggregation that is either too broad or too narrow (23%).

    Nearly two-thirds of developers (62%) said they have found out about errors from users reporting through the application, while a quarter (25%) said that they have heard about errors from users sharing these issues on social media. Another 17% said media coverage clued them in about errors in their software, while more than a fifth (21%) said they heard about them from their CEO.

    Nearly a third of the survey group (31%) said that manually responding to errors makes them feel frustrated, while more than a fifth (22%) said they feel overwhelmed when using manual processes to address errors in software. Nearly as many (17%) said it leads to burnout. More than a tenth (12%) said it elicits feelings of resentment, and 7% said it makes them want to quit their jobs.

    Nearly two-thirds of all developers said they would rather do an unpleasant activity than fix errors, including pay bills (26%), go to the dentist (21%) and spend time with in-laws (20%).

    Rollbar clearly has a vested interest in convincing developers to increase reliance on AI to surface errors in code. The productivity paradox holds that, the more application code developers write, the more time they spend fixing existing code than writing new code. Most developers have a lot better things to do with their time than manually combing through lines of code looking for those errors. In fact, the problem is, many of them simply don’t have the time required to catch all the issues before an application makes it into a production environment.

  • LinearB Aligns with Clubhouse to Advance Project Management

    LinearB Aligns with Clubhouse to Advance Project Management

    LinearB, a provider of an analytics application for software delivery projects, announced today it has allied with Clubhouse, a provider of a project management application that includes built in collaboration tools.

    LinearB’s analytics application uses code, Git logs and releases to automatically construct and visualize detailed timelines without requiring any manual input. That data can now also be automatically fed into the Clubhouse project management application.

    Dan Lines, COO, LinearB, said the goal is to make it possible for any project participant to keep track of updates without spending hours manually compiling and entering data into a project management application.

    In addition, DevOps teams can use both applications to gain visibility into every feature, bug and chore via a live feed of activity generated by branches, pull requests and releases for Clubhouse stories. Along with tools for tracking individual activity and collecting metrics, blockers, delays, high-risk code and branches merged without review for Clubhouse stories are also highlighted. There is also a shadow work detector that detects activity in a Git repository that is not attached to a Clubhouse story.

    Lines said one of the project management challenges organizations face today is the tools they employ only allow them to see segments of a DevOps pipeline. The LinearB analytics application unifies the data and metrics required to make an informed decision, without having to first collect and then normalize data residing in different tools. Instead, all the metrics required to make an informed decision about how best to allocate limited software development resources is automatically collected from the tools the DevOps team employs, Lines said.

    There is no need, then, for project managers to pester members of a DevOps team to enter data in a separate analytics or project management application, Lines added. Given the rate at which application development projects are now updated, much of the data manually entered into a project management application is usually outdated, anyway.

    LinearB employs the application programming interfaces (APIs) exposed by DevOps tools to gather the existing metadata about the status of any given project. LinearB then employs machine learning algorithms to construct and correlate that data to give DevOps leaders more accurate insights into the status of a project, instead of requiring that data to be entered manually.

    In fact, Lines said meetings should be shorter, too, because rather than the need to provide a status update, it will become apparent to everyone what the real status of a project is before a meeting even starts. That means more time can be allocated to determining how best to optimize limited application development resources, Lines said.

    In the wake of the COVID-19 pandemic, organizations have more application development initiatives underway than ever. Many of these projects are core to digital business transformation initiatives which a core group of developers are working on simultaneously. Being able to dynamically reallocate resources to a faster-moving project from one that is stalled is increasingly critical. The challenge has been that the more projects there are, the harder it becomes to collect data that accurately reflects their true status at any given time. The goal should be to eliminate the need to reenter data that, in one form or another, already exists in another tool.

  • ZeroNorth Adds Analytics App to Advance DevSecOps

    ZeroNorth Adds Analytics App to Advance DevSecOps

    ZeroNorth today added an Advanced AppSec Risk Analytics module to its platform for orchestrating DevSecOps processes.

    John Worrall, ZeroNorth CEO, said the analytics tool pulls vulnerability data generated by a variety of security tools to provide both DevOps and cybersecurity professionals with a single source of truth for assessing security within an application environment.

    The ZeroNorth platform is designed to enable IT organizations to orchestrate multiple vulnerability scanning tools within the context of a larger DevSecOps workflow, and can apply analytics to a large pool of security data. That data can be viewed in the context of specific groups, such as a business unit or specific application development and deployment team, or within the context of whichever application generates the most revenue for the business, Worral said.

    Additionally, the Advanced AppSec Risk Analytics module will surface types of vulnerabilities detected and the vulnerabilities most encountered, ranked by criticality, along with other trends in types and number of vulnerabilities detected/remediated, such as the number and criticality of vulnerability findings per specific scanner. It also tracks the applications and entities scanned, number of vulnerabilities detected per application/entity and the applications/entities that have the highest risk.

    ZeroNorth

    Armed with that analytics data, Worral said it becomes easier for IT teams to prioritize and focus their efforts, in addition to identifying areas of the business that may need additional cybersecurity resources and training. IT leaders can also get a snapshot view of the top application security risks to better assess the organization’s overall security posture, Worral noted.

    The Advanced AppSec Risk Analytics module will also surface vulnerability remediation bottlenecks spanning multiple applications within the context of a software development life cycle (SDLC), Worral added. Longer term, Worral said the data collected by the ZeroNorth analytics application will also create an opportunity for the company to apply machine learning algorithms to DevSecOps.

    In general, Worral said the only viable path toward achieving DevSecOps is to foster more collaboration between developers and cybersecurity teams. Getting those teams on the same page in terms of the security data that needs to be analyzed is a crucial first step, Worral said.

    It’s still early on in the adoption of DevSecOps best practices within organizations, however, it’s apparent a lack of cohesion between software developers and cybersecurity teams about which vulnerabilities to prioritize is a major source of dysfunction. Cybersecurity teams tend to create long lists of vulnerabilities discovered within applications without providing much context. Developers are then left to weigh, on their own, when to address a vulnerability versus focusing on writing additional code needed to make an application delivery deadline. Developers take potential vulnerabilities seriously, but there are only so many hours in a day to write code.

    Unfairly or not, developers are being held more accountable for application security. The challenge – and the opportunity – is to find a way to make the entire DevSecOps workflow a whole lot less contentious by helping DevOps and DevSecOps teams more aware of which tasks should be prioritized when.

  • Open Source Advocates Want Share of Wealth

    Open Source Advocates Want Share of Wealth

    The egalitarian spirit of the open source community might be starting to fray as individual developers begin to question who is really benefiting most from their efforts.

    A survey of 4,440 developers who actively participated in open source projects in 2020 finds more than half (54%) of respondents said they feel that individuals should be paid for their contributions to open source projects. The report, conducted by DigitalOcean, a cloud service provider, finds only 14% of respondents are currently paid for their contributions.

    Developer opinions vary, depending on age group, about whether individuals should be paid for their contributions to open source, with those between the ages of 18-25 being more likely to be in favor (60%), while only 34% of those aged 55 or above agreed.

    “A lot more people want to be compensated,” said Raman Sharma, vice president of product marketing for DigitalOcean. “That may mean there will be a need for more sponsorships by vendors.”

    The DigitalOcean report arrives just after Elastic announced it is changing the licensing terms under which it makes Elasticsearch available. Elastic is shifting away from an Apache license to a dual license strategy that includes a server-side public license, or SSPL, along with a proprietary Elastic license. That shift was made to help ensure more of the revenue generated by Elasticsearch winds up in the hands of Elastic rather than cloud service providers, such as Amazon Web Services (AWS), that routinely launch paid services based on open source code. AWS responded to the Elastic move by announcing plans to fork Elasticsearch code that it will now curate.

    Nearly half of respondents (47%) to the DigitalOcean survey said they think technology companies should fund the payment of open source contributions, while a quarter (25%) believe project owners or individuals should pay.

    Discontent among startup vendors has been building for months. Startups typically are backed by venture capitalists, and make their software available as open source code in an effort to build a customer base on the strength of their support services. Cloud service providers have discovered they can take the code these vendors create to launch their own service. Those cloud service providers may contribute code to the project, but the startup vendor doesn’t typically enjoy any of the economic benefits.

    In most cases, the open source code used by the cloud service provider comes from a small cadre of developers that work for the startup company. Most of those startup companies are hoping to build a community around their code that includes individual contributors, external to the company, to help defray those costs. In fact, that business model has contributed to open source projects’ role as one of the primary drivers of IT innovation in recent years. If more independent developers demand to be paid for those efforts, the innovation rate of open source projects is likely to slow. The labor required to support those projects simply won’t be as freely available.

    In contrast, massive open source projects, such as Linux, have already reached a level of sustainability that other projects can only dream of. The Linux community is still ruled by Linus Torvalds, who some say is something of a benevolent dictator. Many of the contributors to Linux, however, are full-time employees working for vendors like IBM and SAP, which have a vested interest in the underlying open source platform.

    In contrast to the Linux community’s approach, the Eclipse Foundation, The Open Infrastructure Foundation (formerly the OpenStack Foundation), the Apache Software Foundation and the various arms of the Linux Foundation have stepped in to provide some level of independent governance for a wide range of open source initiatives, with mixed success. The Cloud Native Computing Foundation (CNCF), for example, as an arm of the Linux Foundation, has played a major role in spurring Kubernetes adoption. However, Google recently spurned the CNCF when it decided to create its own steering committee to oversee development of the Istio service mesh.

    Despite all the internecine rivalries and the potential for more forking of open source projects, overall, these projects are still viewed favorably. A survey of 3,400 developers, conducted by O’Reilly Media on behalf of IBM, finds 94% of respondents said they rate open source software (OSS) as equal to or better than proprietary software. Nearly two-thirds of respondents (65%) also agreed that contributions to open source projects impress potential employers and result in better professional opportunities.

    Of course, one of the primary reasons so many developers prefer open source is that there is no purchasing process for them to navigate.

    “Developers can move faster,” said Todd Moore, vice president for open source at IBM. “Programmers can move at the speed of light.”

    Regardless of motivation, it’s clear open source software isn’t going away. However, how it is built and exactly what is permissible under an open source license may soon vary much more widely from one project to the next.

  • Dual-Track and Low-Code’s Excellent Adventure

    Dual-Track and Low-Code’s Excellent Adventure

    Digital transformation can be a bogus journey. Here’s how low-code and dual-track transformation efforts can help.

    Large-scale enterprise digital transformation can take a while. Transformation initiatives like cloud migration, mainframe upgrades or refactoring monolithic systems could easily take five to seven years. Yet, this slow pace is at direct odds with today’s digital innovation standards and the pressure to release software rapidly.

    COVID–19 has amplified this drive to innovate, especially complicating matters for non-cloud-native companies, which struggle to attract and retain talent amid a developer shortage. Not to mention, developers are experiencing surmounting pressure to perform, which could result in burnout if not supplemented by new strategies.

    To maintain agility while diligently advancing multi-year digital transformation projects, some proponents argue for a dual-track approach. This approach uses low-code platforms to increase operational agility (the fast track) while digital transformation initiatives (the slow track) progress methodically on the side.

    I recently sat down with Jay Jamison, chief product and technology officer at Quickbase, to discuss today’s digital transformation concerns. According to Jamison, implementing a dual-track approach affords great rewards, but it requires an organizational cultural shift. He recommends establishing centers of excellence (COE) to evangelize low-code practices and encourage citizen development, enabling subject matter experts of lower technical acuity to automate operational workflows and operations.

    Dual-Track Transformation

    “Digital transformation is an important element for businesses of all sizes,” said Jamison. However, mainstream digital transformation projects, like rationalizing an ERP, moving to the cloud, or upgrading a network, can take an exorbitant amount of time and money. It’s hard for IT to meet business requirements. “We really need a second track of digital transformation — one that is more agile.”

    Jamison likens dual-track transformation to chipping out “small rock” projects from the larger digital transformation cliff. This strategy focuses on streamlining realizable goals in shorter timespans, empowering teams of people — with subject matter expertise — with tools to transform and digitize their workflows.

    Low-Code’s Role in Dual-Track

    A recent study conducted by Harvard Business Review found that 80% of executives “strongly agree” that a dual-track approach is essential for digital transformation. Yet, only 31% of companies have adopted said approach.

    To realize a dual-track process, Jamison recommends low-code for its “low-risk, high-throughput capability.” According to Jamison, low-code enables the edge of business to quickly adapt new solutions and run them in parallel with big rock digital transformation. For example, non-engineer government employees in a Texas county recently used a low-code platform to help distribute coronavirus vaccines.

    For a citizen developer culture to flourish, “you really need to have all hands in the pile,” Jamison said. IT stakeholders and business members must collaborate and work together to bring low-code to fruition. This process combines setting goals, outlining guardrails, and forming learning groups with progressive leadership at the helm.

    Introducing Centers of Excellence

    Naturally, many factors can affect IT innovation (leadership commitment, collaboration, organizational expectations, etc.). But arguably, the most common roadblock to digital innovation is culture. In fact, 45% of executives report that organizational structure is a major transformation challenge.

    That’s where centers of excellence (COE) come in. No, centers of excellence is not an archive of Bill & Ted’s adventures. COEs aim to fix the cultural barrier by encouraging progressive leadership, collaboration, and innovation. The Playbook for Centers of Excellence defines COE as “a concentration of expertise and resources in a specific capacity, designed to maximize the focus on a specific project.”

    A COE aims to foster shared understanding between IT leadership and business leadership. In Jamison’s words, “a center of excellence provides the ability to utilize low-code to sustainably build and empower applications in a safe, sustainable way.”

    Building a Most Triumphant Center of Excellence

    The COE goal is to empower business users to innovate. Yet, COE is a governance framework, which seems a bit contradictory. So, how does an organization go about implementing it? Well, there is a range of how companies adopt COE, but Jamison shared some common steps:

    Step one is establishing your goals. This could be increasing productivity, enhancing customer satisfaction or improving service reliability. Step two involves inviting the right people and perspectives — the key personnel to own the COE program.

    Next, develop transparent policies around security. This helps preempt concerns around data security and compliance. Finally, now that goals and rules are established, communicate the initiative across an organization.

    Throughout this process, investing in training is paramount. There are many project management philosophies for encouraging low-code adoption, but Quickbase recommends a training and education team to “roll out information and goals in a structured, targeted way”. They also encourage a community focus — user groups, internal events and knowledge-sharing initiatives can build excitement within the employee base.

    Benefits of Low-Code Enabled COE

    A COE aims to bring disparate parties to the same table. For example, companies could hold what Jamison described as an “appathon,” in which business executives present their goals, like rolling out new installations or driving 5G deployments. Then, priorities are assigned to individual groups, who apply domain knowledge to construct applications.

    Setting up a COE by accelerating ground swell innovation “catalyzes the dual-track innovation that we think is really key,” said Jamison, reducing the mean cycle-time to introducing new features. Low-code could also lower the integration barrier, enabling connectivity with CRM systems, or connecting with big, heavy systems like SAP or Oracle.

    Jamison also described low-code platforms as encompassing “the spirit of microservices,” as they introduce a relatively lightweight application process and easy deployment model. Furthermore, if teams are tapped into the same PaaS, they receive data reusability benefits, he said. “Everyone can utilize the same data in a way that’s relevant for what they need.”

    Citizen Developers: Bogus or Non-Bogus?

    Personally, I think it would be great if the future of application development ushered in a democratizing effect, allowing more people to participate in software creation. Yet, the skepticism around a fully working citizen developer model is hard to shake.

    The “citizen developer” seems to have a negative connotation among coder elites, too. As one reader commented:

    “So top talents are overpaid extravagance and bored secretaries working from home will be driving innovation by writing no-code workflows, am I right with understanding what is written here?”

    I pressed Jamison on the reality of the citizen developer concept in practice and how he responds to naysayers. He jokingly equates it to a witch hunt.

    “Saying that only people that get to participate in software development is professional software developers is ridiculous,” he said, noting the importance of subject matter expertise.

    According to Jamison, companies often fail when they attempt to transmit subject matter expertise to developers. Organizations would rather teach subject matter experts low-code than teach the subject matter to programmers, he noted. It’s not hard to imagine why allowing subject matter experts to build their own workflows for specialized fields, such as accounting, natural science, or mathematics, makes sense.

    Regardless, Jamison adds there’s nothing really to worry about — “The full stack developer isn’t going anywhere.”

    Dual-Track Digital Transformation? Excellent!

    A dual-track approach combines large-scale transformation and rapid-cycle development. By separating “small rock digital transformation” out from the larger puzzle, organizations can increase operational agility to meet business needs a bit quicker.

    Establishing a center of excellence seems to boil down to bringing people together to share ideas, collaborate, and drive better productivity. If anything, this way of thinking will help operationally-intensive industries consider how they can automate parts of their business.

    Ultimately, the goal here is to enable organizations to collaborate better and drive better productivity. By empowering more creators, you can start seeing creativity at the edge of business emerge too, said Jamison. If that involves citizen developers creating event-driven workflow automation, so be it. “We invite people to take on the challenge,” said Jamison.

    Hopefully, then, business and IT can be excellent to each other.