devopsy.kinsta.cloud

Category: Enterprise DevOps

  • CircleCI Adds CI/CD Service for macOS Development

    CircleCI Adds CI/CD Service for macOS Development

    CircleCI today added a dedicated continuous integration/continuous delivery (CI/CD) edition of its namesake platform for developers building applications on the macOS platform.

    Jim Rose, CircleCI CEO, said this offering is aimed at developers that either want dedicated resources to speed up their build processes or have to address compliance and security requirements that prevent them from using shared infrastructure via the existing CircleCI cloud service.

    Most of the developers building applications on macOS platforms are creating applications that will ultimately be deployed on Apple iOS devices, noted Rose. Given the popularity of those devices, the number of organizations using CI/CD platforms to accelerate creation and updates of those applications has increased, Rose added. CircleCI estimated there are now more than 30 million developers building applications on the macOS platform that would benefit from a CI/CD platform running on dedicated bare-metal infrastructure accessed via the Amazon Web Services (AWS) cloud. CircleCI’s dedicated host provides secure access to 50% more cores and more than twice the storage capacity than is available via a CI/CD platform running on top of virtual machines.

    Other capabilities provided by CircleCI include the ability to monitor the performance of apps being developed for multiple platforms in the same pipeline. Many applications deployed on iOS are also deployed on other platforms such as Android, Windows or Linux, noted Rose.

    CircleCI also provides access to testing tools that the company recently added to its portfolio of DevOps tools. Those testing tools are especially critical given the stringent requirements developers face when trying to get approval to make their iOS applications available via the Apple Store, said Rose.

    Developer productivity is, of course, a major issue for organizations trying to strike a balance between automating software development tasks and the art that goes into building applications. While developers appreciate automation, they don’t necessarily want to feel they are working in a factory. Given the demand for their expertise, many developers will simply jump ship when they feel software development processes have become overly onerous. While many managers tend to believe they have a handle on measuring developer productivity, there is often too much focus on, for example, how many lines of code are written versus the business outcomes achieved.

    A recent CircleCI survey also found that more than half (52%) of respondents don’t allow their software developers to choose their own tools. While there is a clear need for a consistent approach to building and deploying applications, organizations will find it challenging to attract and retain the best developers if they don’t allow them to experiment with different tools.

    One way or another, however, the rate at which developers can build and deploy applications is rising as DevOps best practices are adopted. It’s not clear that organizations are going to be able to absorb all that software but, in the wake of the COVID-19 pandemic, the appetite for mobile applications that drive digital business transformation initiatives has never been greater.

  • Watch Your Language(s)

    Watch Your Language(s)

    Just about every organization I am familiar with today is using more languages, frameworks, libraries, etc. than they were a decade ago. Back then, most organizations were doing a lot of Java, and maybe a little bit of PHP or .NET (almost always VB.NET). Now we have Java, Python, Ruby, Go, Swift, etc. And etc., etc.

    The problem is that employees don’t come pre-instructed with your selection of languages. Most developers can bring Java or Python and most know at least one other language well. All of them can learn (more on that in a moment), but when hiring, an organization needs to focus on the one or two languages the hiring team is using, not all the languages an organization might ask a developer to learn over the course of their employment. After all, when hiring 20 years ago, the tools of the mainframe team weren’t generally listed as requirements for a desktop developer. While there is a difference (desktop developers were only asked to work on mainframes when the shortage of experienced big iron devs got really bad), it is a similar situation today.

    You can hire with an eye to training, and most developers will be more than willing to pick up a new language and learn its ins and outs. But ask any manager that pays close attention, and they’ll let you know that there is a huge difference between time-to-productive and time-to-proficient. One manager told me that any programmer with experience could start contributing relatively quickly in Ruby, but to do the important stuff—things like knowing which array access methods were faster and the most efficient communication between Ruby and other languages—took far longer. His numbers seemed too high, in my opinion and based on my experience, so I asked around. All the managers I know that worked with Ruby (because to a great extent, this is language-dependent, so I didn’t want to make hasty generalizations though, in hindsight, the same data point in Python would have given me more responses) agreed there is a curve, and the range was somewhere between six months to two years. This is strictly anecdotal, but it seems the more technical the team in question, the longer the manager thought proficiency would take.

    But even if the lower number is accurate and applies more generally, it is an argument for keeping your language count down. Yes, some languages are better at X or Y or Z than others, but most modern languages can do just about everything an average enterprise team will ask of them. So, keeping languages within a smaller pre-defined set still allows teams to choose the best tool for the job while keeping the number of skills developers at the organization might need down to a manageable level.

    And keep wowing them. No matter what languages you are using, your user base is logging in and using the results daily—or perhaps your devices are reporting the results daily or processing them. No matter how you are delivering, you are, as our digital world shows. Keep rocking it, and do what you can to keep the number of languages under your roof down.

  • Graph CDN for GraphQL APIs

    Graph CDN for GraphQL APIs

    Alan Shimel talks with Max Stoiber from GraphCDN, the CDN for GraphQL APIs. GraphCDN is now available to everyone with edge caching, query analytics, error tracking and protection from malicious queries for your GraphQL APIs. A video is below followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Thanks for joining us on another Tech Strong TV segment. My guest for this segment is Max Stoiber—and if I mispronounced that, Max, I apologize. I did my best, but why don’t you say it correctly?

    Max Stoiber: Stoiber, but it doesn’t really matter. I’m really excited to be here—thank you for having me.

    Shimel: Oh, it’s our pleasure to have you on. But you know what, it does matter—names matter, right? My mom taught me that and somewhere, your mom or dad or both, their name and—they deserve to have it pronounced right, as well.

    But anyway, Max, thanks for joining us. Maybe more important than your name is the name of your company, so why don’t you start off with sharing that with our audience?

    Stoiber: Absolutely. So, I am the Co-founder of GraphCDN, which we just recently announced is now publicly available for everybody. And so, that’s sort of the reason I’m here is to tell you a little bit about that journey and how we got here.

    Shimel: Absolutely. So, GraphCDN—I mean, we’ve seen so much news coming out of kinda graph databases and graph data, and it really gives us a new way of looking at, I guess it’s part of nature, right? Things get more complex and bigger as we go on, and so you need new technologies to help you get your arms wrapped around it. And certainly, graph technology is a real up and comer, if you will, in terms of helping us wrap our heads around stuff like this.

    So, you know, why don’t we start with a little bit of background? Like, what does the company do, what’s the problem you’re solving—that kind of thing.

    Stoiber: Absolutely. So, GraphCDN is a GraphQL CDN. And GraphQL is a technology, in case you’re not familiar with it, that was invented by Facebook back in, I want to say 2014, maybe ’15. It’s been a while. And they use it—it’s basically like an API framework that lets people build very strongly typed APIs to communicate between their servers and their clients. And Facebook invented that, and open sourced it. And a lot of other companies started adopting it, because it feels very nice to use for developers.

    And so, we provide, similar to how other CDNs provide features for websites to make them faster, more secure, think, like, Fastly cloud there, we do the same thing for GraphQL APIs. And we do that for everybody, not just Facebook who has technology like this internally, of course, we do it for all the other companies that aren’t Facebook and don’t really have the time to build all this technology themselves.

    And we came to that whole thing because when we built our last status, me and my Co-founder Tim, we were using GraphQL and we had huge scaling problems. We were growing like mad, but we couldn’t just cache our GraphQL API, for example, because none of the existing CDNs support GraphQL. They can’t cache any of the data that goes through it.

    And so, we struggled with this and we built terrible solutions internally at our past companies, trying to solve this as best as we can. And then now, we got together and we said, “Hey, we just gotta solve this,” right? It’s almost, excuse my language, stupid that nobody’s done this, because it’s such a clear need.

    And so, we sat down, and it turns out it’s quite hard to solve, which is why it took us a while, but we finally got there and now we’ve got GraphCDN, and it does a lot of things for people that have GraphQL APIs. That’s sort of the broad strokes overview, I would say.

    Shimel: Absolutely. Max, you know what, you mentioned a little bit here and there, but let’s talk about your background and your history.

    Stoiber: Absolutely. So, I am, I would say, most widely known in the engineering community for having invented a bunch of open source projects, particularly in the front-end web development space. About 1 to 1.5 percent of all websites on the planet are powered by technologies that I invented, mainly by styled-components, which is one of the biggest ones.

    And so, I’ve sort of amassed a large following of engineers and designers and other tech people following me for my open source work. And then, I’ve previously co-founded a startup with two friends from California where we were building sort of a modern forum, in a way, sort of a mixture between WhatsApp and traditional, you know, the forums of the past where we used to hang out and have friends.

    That was then acquired by GitHub, and turned into GitHub Discussions so that the engineers on GitHub can then sort of hang out. And then I had a stint at GatsbyJS, another startup, that was building a JavaScript framework, or is still building a JavaScript framework, and I left that at the beginning of this year to focus on GraphCDN and really build that out with Tim. And sort of, that’s my background.

    Shimel: Very cool, and congratulations. Very, very impressive.

    Stoiber: Thank you.

    Shimel: Thank you. You know, look, I’ve worked with enough engineers and software developers to know that nothing is ever truly done, right? There’s always more we could do, right? Why GA now, why kind of emerge from Stealth, if you will—you know, why now?

    Stoiber: That’s a great question. It’s funny, because we debated this for a long time internally, because we felt like we were GA ready two or three months ago, right? We sort of had the basic set of features where we thought we could cover common needs, almost all of the common needs that we wanted to cover. We were ready or people, but also, GraphCDN, because it is a CDN, is critical infrastructure. If we’re down, our customers are down. And we take that responsibility incredibly seriously.

    Now, we’re based on Fastly’s edge computing technology. So, the infrastructure underlying GraphCDN is actually very solid. But we wanted to make sure that our part of that infrastructure was as solid as it could be. And so, we gradually on boarded early access customers, including the biggest rugby site in Australia and a bunch of others, to make sure that our infrastructure could really handle the load. And after we proved that out for the last two, three months, we said, “Okay, we are confident in our systems, we’ve found all the bugs we’ll find before with GA.” Of course, you can never find all of them. That would be—I think any engineer that says that is lying. But we found most of them, the ones that really mattered, and then we said, “Okay, it’s good enough, let’s have people sign up and really get this into people’s hands.”

    Shimel: Excellent. And let’s talk about the model for the company. I mean, with your open source background, I’m gonna assume, is there an open source graph?

    Stoiber: There actually isn’t.

    Shimel: No?

    Stoiber: The open source part of it is the GraphQL part, the framework that Facebook open sourced. But our infrastructure is fully proprietary. There’s actually—there’s sort of two schools of thought, right? You have companies like Sentry doing all of their core work in the open source and then providing hosting or other services on top. And I think that model can work quite well, but for us, because we’re critical infrastructure, we knew that we needed to be in people’s critical path and we knew we needed to be reliable, and that just takes a team, right? There’s no way that you can just run this on the side, you know, have it running in the background and not worry about it. It needs to be maintained. Somebody needs to sit there 24/7 on call and pay attention that this thing keeps running, just to make sure nothing goes wrong.

    And so, open source just didn’t feel like the right fit for that, because honestly, we’re gonna sit there 24/7 and make sure that our infrastructure stays up and doesn’t have any down time. And so, we did not go open source and instead have—we have a very generous fee plan, but beyond that, believe it or not, people pay us for the thing we provide. Which, of course, sounds ridiculous, because that’s what businesses do, but as an open source developer, that’s actually less natural to me than you might think. But it feels very nice, I have to say. We’re very appreciative of our customers for helping them scale and secure their GraphQL APIs. And so far, over the past months that we’ve had customers, everybody has been very happy that they have us and that’s very gratifying to see from our side, of course.

    Shimel: Agreed, agreed. When you say GA, I’m assuming GA, people can go buy and use this right now.

    Stoiber: Correct. Absolutely.

    Shimel: But is there a free trial, is there—

    Stoiber: Yes.

    Shimel: You know, because you know how software is consumed today, right? You gotta get it in people’s hands and deliver delight, right?

    Stoiber: Absolutely.

    Shimel: And if it’s good and they like it, they buy it.

    Stoiber: Absolutely. That’s the exact model we follow. We have a very, I would say, generous free plan. You can use us for free for up to, I think, 5,000,000 requests per month, which covers a lot of early stage startups, we’ve realized, maybe even more than we would’ve liked. It’s definitely a very generous free plan, is what we’ve learned, which is a good thing, because we wanna provide that value, particularly to those growing companies. And then eventually, when they hit the scale where they have more than 5,000,000 requests, it starts costing $10.00 per 1,000,000 requests. And so, it’s sort of, the pricing scales with your usage.

    In theory, you can throw as many requests as you want at us, since we’re based on Fastly and they handle a lot of traffic, I’m not very worried about not being able to handle scale. And we have—it was actually funny, after we GA’d and we announced that this is now available to everybody, of course, people signed up and then suddenly started deploying this thing to production and our traffic just 10X’d overnight, and we didn’t even notice. Like, we just looked at our graph, like, we woke up the next morning, we looked at our graphs, at our internal dashboards and we realized, “Hey, a site just enabled us overnight and 10X’d our traffic, and we didn’t even realize,” right? And they’re just—they were just like, “Yeah, this works, we’ll use it—perfectly fine.” And that just kind of keeps happening and it’s very, very interesting to see. I love it, I have to say.

    Shimel: You know, that’s one of the—so, I’ve been in the Internet business since ’96, ’95, and that truly is one of the remarkable things about the Internet is yeah, people, you know, if you put your shop out there, you put yourself out there, people come by. And they could be from anywhere, whether they’re from Australia, Japan, Korea, you know, Amsterdam, London, or next door, it makes no difference, they’re on the Internet. And all of a sudden—boom, you know, it lights up and it’s like, “My goodness, you know? We were hoping for this, but who”—you know, you never know. That’s fantastic.

    So, what are plans going forward? Have you guys announced fundraising, is that in the works, or—you know, where’s the continuing journey, here?

    Stoiber: We raised a round of funding a couple months ago from some well-known industry people, mostly friends of ours, like Guillaume ________, the CEO of Versel; Tom Preston-Warner, one of the Founders of GitHub; Jason Warner, the current CTO of GitHub. A bunch of friends that we knew from the industry that we also knew loved GraphQL and that they knew what it was about and they immediately got what we were working on.

    And so, we raised enough funding to sustain us for a couple years, and now we’re gonna use that funding to build a small team to help us maintain this, because right now, it’s just me and Tim—or has been just me and Tim for the past months, and now we’re starting to hire and on board the first people to help us really take this to the next level. Because it’s a lot of work, it turns out. [Laughter]

    Shimel: Yeah, I know, yeah.

    Stoiber: Building a great product is a lot of work.

    Shimel: Well, you know what they say, Max, if it was easy, everyone would do it.

    Stoiber: Exactly right. [Laughter] Absolutely.

    Shimel: But it’s fun work, right? There are people who really work for a living versus people who love what they do.

    Stoiber: Yeah, absolutely.

    Shimel: You know what we didn’t do, though, Max, we never gave anyone, like, the URL, where could they get more information, where can they download it? Where can they go?

    Stoiber: The URL and the home page is at GraphCDN.io, and it just has—as any website, it has a massive sign up button that you can click, and then you’ll be redirected to GitHub and you can sign up and just try it out. You don’t even need a GraphQL API, we have this sort of flow where we’ll give you a demographical API, just so you can get a feel for what it does and how it works. So, yeah, go to GraphCDN.io and try it out.

    Shimel: That sounds like a plan. Hey, man, you gotta come back and keep us posted of progress here, okay?

    Stoiber: I will absolutely do that. Thank you so much for having me.

    Shimel: Oh, it’s our pleasure. Max Stoiber, Co-founder, GraphCDN, it’s at GraphCDN.io—right, Max?

    Stoiber: That’s it. That’s the one.

    Shimel: Yeah. Go check it out. Seems pretty cool. This is Alan Shimel for Tech Strong TV, we’re gonna take a break and we’ll be right back with our next guest.

    [End of Audio]

  • Will Splunk be Gobbled up by Cisco?

    Will Splunk be Gobbled up by Cisco?

    Word on the street is that Cisco and Splunk are in discussions about a possible acquisition. Splunk, the technology monitoring, search and analytics company could be acquired by Cisco—originally a networking company but now a complex hardware and software conglomerate.

    Splunk has generated quite a reputation as a ‘dealer’ over the years. The company, much like a drug dealer, gets you hooked and then, when you can’t live without what they’re selling, makes you pay. The difference is that what they’re selling is insight and visibility into your own data.

    For many years, Splunk’s pricing model was simple—customers paid for the amount of data that was ingested. Splunk didn’t invent this type of pay-for-what-you-use-and-consume model. For mainframe workloads, IBM has long charged clients based on millions of instructions per second, or MIPS. Likewise, the entire cloud computing business model is based on a pay-for-what-you-use model. If, for example, you leave an AWS experimental instance running over the weekend or while you’re a vacation, you’re going to pay for it (many of us have learned that the hard way).

    So why am I picking on Splunk for being a dealer? The whole value proposition of Splunk is that the more data it ingests, the more useful the software platform can be. Splunk can help operations and security teams connect disparate data points to uncover potential emerging problems or greatly reduce the time it takes to resolve an incident. However, to unlock the power, you need to push more and more (and more and more) data into Splunk.

    But here is where Splunk gets down and dirty: Like any dealer, Splunk will give teams free trials and the ability to ingest data from new areas of your business for free. Once a team starts to see the value and is hooked on the software, the Splunk sales team is right there to take your money.

    Splunk now offers other pricing models, but the stigma sticks.

    Splunk Customers are the Company’s Best Salespeople

    Splunk has done an excellent job at creating evangelists out of their existing client base. I’ve attended a lot of vendor conferences, and my experience is that Splunk’s customers are some of the most enthusiastic I’ve ever encountered. What does user enthusiasm tell me about a vendor’s product? It is either that the product is making that employee a superstar within their company or making that employee highly desirable across the broader technology market.

    At Splunk events when I have candid conversations with customers, the adoption pattern follows a fairly standardized script. The IT operations team adopted Splunk. IT operations had a ton of success and shared that with the rest of IT. Security saw ops’ success and wanted to try Splunk out for themselves. In many cases, the cybersecurity use case within the company became the bigger Splunk deployment once the platform’s capabilities were understood.

    So Why Would Splunk Sell?

    Customers like Splunk and they’re obviously seeing value. So, why would a company like that ever sell? Well, first of all, the SIEM 2.0 market vanished; security log data analysis is table stakes. What do I mean by that?

    So Long, SIEM

    The idea of security information and event management (SIEM) hasn’t gone anywhere, but now security vendors need to do more than just SIEM.

    It wasn’t long ago that those of use following the security industry tracked RSA Netwitness, Logrhythm, IBM Qradar, HPE ArcSight, RSA Archer, Carbon Black and other SIEM vendors. The reality is that all of these companies have gone through massive transformations. Those of you reading this article might be surprised by the companies that now own many of these SIEM vendors!

    Splunk is no longer unique in its approach to applying machine learning and artificial intelligence to security log data.

    AIOps—The Company Lost its Focus

    Splunk cut its teeth with operations teams. The company helped ops teams quickly find the root cause of disruptions and spot problems before the pain was felt by customers. However, operations isn’t sexy. Rather than doubling and tripling down on operations, the company expanded to security. It made sense; security organizations deal with huge amounts of complex data.

    However, as DevOps rose to prominence, Splunk has been widely left out of the conversation. DevOps teams need software tools that can normalize data across job function-specific software platforms. This would have been a perfect opportunity for Splunk—however, new competition stepped in to fill this gap.

    The World Evolved—Businesses Need Observability

    SIEM 2.0 was hot—“was” being the operative word. Today, DevOps and DevSecOps teams are looking for observability offerings. Observability tools provide teams with the ability to understand and see what is going on within systems and software from a variety of perspectives. Observability platforms can view system and cloud health and resiliency, but can also give operations teams container-level data.

    Enter the Observability Vendors

    By no means is this a comprehensive list, but my colleagues at Techstrong Research and I have come up with a list of observability vendors you should be paying attention to. Some of these vendors are pure-play observability companies while others, like Splunk, have a variety of offerings.

    •   Splunk
    •   Sumo Logic
    •   Logz.io
    •   StackState
    •   Lightstep (acquired by ServiceNow)
    •   Dynatrace
    •   App Dynamics
    •   VMware – Tanzu
    •   AWS CloudWatch
    •   Azure 
    •   Honeycomb.io
    •   Grafana Labs

    Acquisitions

    •   IBM acquired Instana for observability and Turbonomics for AIOps
    •   Cisco acquired Epsagon
    •   Cisco acquired AppDynamic for $3.7B for application performance management/monitoring
    •   VMware acquired Mesh7
    •   GitLab acquired observability distribution Opstrace 
    •   NewRelic acquired CodeStream
    •   Splunk acquired SignalFX, FlowMill and Omnition
    •   ServiceNow acquired Lightstep

    Within the observability space, there is also a tremendous amount of open source. Many vendors are coalescing around the OpenTelemetry project, for instance, that focuses on collecting data. This type of open source use makes sense—vendors should focus on areas of differentiation and customer value rather than just data collection.

    Open Source related projects

    • Prometheus
    • OpenTracing and OpenCensus from Google (folded into OpenTelemetry)
    • Zipkin (Twitter) one of the first open source tracing projects

    Why Would Cisco Want Splunk?

    Splunk’s stock has been in decline since its CEO left in Q4 of 2021. Like other technology companies, inflation and a general technology sell-off is further impacting its stock price. In addition, the company is transitioning clients to cloud-based offerings, which is often a painful process for public companies (many companies have gone private to eschew Wall Street’s prying eyes).

    Cisco has, historically, occupied the network layer. Splunk understands network data and can offer many benefits to Cisco clients.

     Splunk is an enterprise software vendor that can scale in a non-linear way if Cisco can add stability to Splunk’s leadership and vision.

    Now, will the deal for Splunk get done at $20 billion? No. But a possible acquisition is very possible, especially given the fact that Splunk’s runway is short and getting shorter.

  • IBM Shifts Mainframe App Testing to the Cloud

    IBM Shifts Mainframe App Testing to the Cloud

    IBM this week revealed it has added the ability to set up testing environments on the IBM Cloud for z/OS mainframe applications.

    In addition, on March 15, IBM will make available an IBM Z and cloud modernization stack to make it simpler to modernize mainframe applications by adding application programming interfaces (APIs) using a cloud-native set of DevOps tools that run in a Kubernetes environment.

    Tarun Chopra, vice president for the IBM Z Hybrid Cloud, said IBM Z as-a-service on IBM Cloud for development and test eliminates the need to dedicate mainframe capacity to an application testing environment. Instead, mainframe application testing can now occur in the IBM Cloud, he added.

    Currently available as a closed experimental today, IBM plans to make IBM Wazi as-a-Service (Wazi aaS) for z/OS generally available in the second half of this year. That offering will enable DevOps teams to self-provision an instance of a z/OS virtual server on a secure private space running on IBM Cloud.

    That hybrid approach means application testing no longer disrupts mission-critical applications running in production environments on a mainframe, added Chopra. The overall time required to gain access to a z/OS development and test environments will drop from days or weeks to six minutes or less, he said.

    At the same time, it will become easier to modernize mainframe applications by making them more accessible to other applications via a set of secure APIs. Many organizations today increase their technical debt by duplicating functions that already exist within mainframe environments simply because those functions are not easily accessible to developers. The IBM Z and cloud modernization stack makes it simpler to modernize mainframe applications to drive a digital business transformation initiative without increasing the overall technical debt an organization needs to service, noted Chopra.

    While many workloads over the years have been migrated off mainframes or simply retired, the applications that run on z/OS today are still among the most mission-critical that organizations run. A recent IBM Institute for Business Value study found 71% of respondents said mainframe-based applications are still central to their business strategy. Four out of five respondents also noted they needed to modernize those applications, as well.

    Modernizing mainframe applications is a less complicated endeavor than migrating them. The challenge is that building, deploying, maintaining and securing all the APIs required to do so represents a significant amount of effort. IBM said it is committed to simplifying the mainframe app modernization process.

    One way or another, mainframe applications are becoming part of the larger distributed computing environment. Most organizations that have invested in mainframe applications continue to run them in on-premises environments because of the unique transaction processing capabilities a mainframe provides. Mainframe applications that have been migrated to the cloud generally run more slowly than they did when running natively on a mainframe. There may still be circumstances where migrating a mainframe application to the cloud makes sense as part of a larger IT strategy. However, like every other application being accessed over a wide area network (WAN) there will always be performance tradeoffs to consider.

  • Dynatrace Advances Application Environments as Code

    Dynatrace Advances Application Environments as Code

    Dynatrace, at its online Perform 2022 event, launched a bevy of updates to its portfolio that make it easier for DevOps teams to programmatically embed observability and other software intelligence capabilities within applications.

    At the same time, Dynatrace also revealed that it has extended the reach of its observability platform to now include all the major serverless computing platforms.

    Additionally, the company extended its existing Application Security Module to provide the ability to detect vulnerabilities and block attacks against application runtimes in real-time using the framework defined by the Open Web Application Security Project (OWASP). That module is based on Dynatrace Smartscape topology software and a Davis artificial intelligence (AI) engine to provide real-time visibility into IT environments that enables DevSecOps teams to better prioritize which vulnerabilities to remediate first based on their severity.

    Dynatrace CEO Rick McConnell told conference attendees that all these capabilities are enabled by agent software that can be programmatically embedded within applications as code using application programming interfaces (APIs) and templates to automatically surface software intelligence. Rather than having to deploy multiple agents, McConnell said, IT teams can deploy a single agent to drive a wide range of analytics.

    That capability makes it easier for IT organizations to achieve service level objectives (SLOs) for performance, quality, and security at a time when more responsibility for the management of applications is shifting left toward developers, he added.

    It’s not quite clear how far responsibility for the management of applications after they are deployed is shifting left toward developers. It tends to vary widely by organization. The one thing that is certain is more applications are being instrumented. Adoption of application performance management (APM) platforms was previously limited by cost concerns and the challenges associated with embedding agent software in applications. As it becomes easier to instrument applications the data that can be collected and analyzed from logs, metrics and traces are now considerably greater. As such, APM platforms are now being positioned as observability platforms that can correlate analytics collected from applications and the underlying infrastructure upon which they depend.

    Much of that need for greater instrumentation is being driven by digital business transformation initiatives, noted McConnell. Many of those applications are being constructed using microservices that have dependencies on each other. A single agent makes it easier for IT teams to instrument cloud-native application environments, he noted.

    There is no shortage of options when it comes to instrumenting and observing applications. The issue now is turning all the data being collected into actionable intelligence. As a result, observability platforms are being imbued with AI engines that make it possible to analyze massive amounts of data. Armed with those insights, it then becomes possible for an existing IT team to manage a much more complex IT environment at scale. In fact, it’s now no longer a question of whether AI engines will be injected into DevOps workflows as much as it is to what degree.

  • Kong Enterprise 2.7 Simplifies API Management

    Kong Enterprise 2.7 Simplifies API Management

    Kong Inc. this week advanced its service connectivity platform strategy with an update to Kong Enterprise that makes it simpler to collectively manage groups of application programming interfaces (APIs).

    Michael Heap, director of developer experience for Kong, Inc., said that capability will make it simpler to, for example, assign rate limits to different tiers of APIs.

    In addition, Kong Enterprise version 2.7 adds support for real-time and event-based use cases involving the open source Kafka streaming platform and webhooks. Usage of event-driven architectures is rising as more organizations embrace digital business transformation initiatives that require near-real-time processing versus relying on traditional batch-oriented applications, noted Heap.

    Finally, IT teams can now also securely store secrets such as user names/passwords, API tokens, database credentials and private keys that might be used to access Kong Gateway. An improved user interface for Kong Manager UI makes it simpler to configure the Kong OpenID Connect (OIDC) Plugin for the Kong Gateway.

    Overall, Heap said, the latest update also provides 25% increased throughput and improved latency. In tests run by GigaOM, a third-party research firm, Kong Enterprise 2.7 achieved 52,250 transactions per second (TPS) maximum throughput with a 100% success rate.

    Kong is making a case for a service connectivity platform that enables an IT team to manage APIs at a higher level of abstraction by integrating all Layer 4 through Layer 7 services for both monolithic and microservices-based applications. Rather than having to manage an array of networking services and associated services in isolated silos, that layer of abstraction makes it simpler to manage distributed applications that have dependencies on a wide range of APIs.

    In general, the number of APIs that organizations are using both internally and externally has expanded tremendously over the last several years. The challenge now is finding a way to not only manage and secure all those APIs but also retire them as new services come online. Many APIs are created and simply forgotten about because their developer neglected to inform IT operations of their existence. Those so-called “zombie APIs” then become a cybersecurity liability when cybercriminals discover they can surreptitiously exfiltrate data via those APIs.

    APIs are, of course, an integral element of any software supply chain. But as high-profile security breaches put software supply chain security in the spotlight, it’s only a matter of time before IT teams look for more efficient ways to manage and secure APIs at scale.

    Inevitably, that also means organizations will need to decide how much they want to rely on proxy software, API gateways and service meshes to achieve that goal within the context of a larger service connectivity platform.

    In the meantime, the days when APIs were managed in isolation from the rest of the IT organization are coming to an end. The only thing left to determine is how involved API developers need to be in their ongoing life cycle management.

  • No Matter How Things Change, Have a Plan

    No Matter How Things Change, Have a Plan

    Had enough change yet? It is almost amusing that I and some other tech people had that conversation a decade ago, and since then, nothing has slowed down. Our conclusion was that, for the near future, change would be constant. That conclusion was right; I’d have to ping everyone else to see what they think, but “near future” turned out to be longer than I expected.

    Inevitably, though, change requires taking a breather at times. It appeared that high-tech was finally ready to admit that burning out your staff was not a viable long-term business model, and was slowing down … and then, COVID-19 hit. Now I’m hearing rumblings about going back to non-stop change as if the last couple of years were a vacation and staff is all rested up and ready to replace massive chunks of the infrastructure.

    The reason that change requires intermissions, though, is not 100% about staff and burnout. That only shows up when you’re making a ton of change non-stop. Before staff burnout becomes an issue, recovery and business continuity plans become outdated. At the rate we’ve been running, I’d go so far as to say they are likely useless.

    Yes, all this change has brought us some cool stuff. While we are busier, some of the busywork is far easier, or even non-existent now—but that doesn’t change the fact that you need to breathe. This is a perfect time to go over plans to keep the business on its feet in case of IT catastrophe—or at least some major systems catastrophe. Saying “We’ll just deploy a new version” is cool, but it only works in some scenarios. I touched on this and discussed one case where it doesn’t work in October 2021. But there are a ton more. Every environment is different, but hardware failures have not disappeared and destructive writes still occur, as just two more examples. Your infosec team can give you a few more examples.

    Knowing what you’re going to do when the worst-case scenario happens is huge. And for those who’ve never been through it, knowing before people are stressed and asking you for a timeline will save you a lot of headaches.

    For those who’ve never had a DR or business continuity plan, consider it. At least have a basic DR plan that lists critical systems, things most likely to go wrong and what the steps are to recover it and get things moving again. The process of making such a list will often uncover things that should be done but aren’t—like backups or backup verifications.

    For those with a DR or business continuity plan, I’ll take a wild shot and say, “It’s out of date.” Organizations tend to create them and then forget about them. These plans should involve a bit of each project, so it’s taken care of in bite-sized chunks, but—probably because the first implementation of DR or BC is normally a massive project—it tends to be set aside and revisited every few years. Don’t do that.

    As I’ve said before, you and yours have built the heart of the modern enterprise. Don’t forget to protect it. It doesn’t take much to use some of these sweet new technology advances to put in DR procedures. Tack DR review/updates onto each major initiative, be it a new product or a big change to existing software. And keep rocking it. If you have a say in your organization, consider slowing the pace down for a bit and even updating DR. If you don’t have a say, may your employer be wise enough to do so.

  • Techstrong Research DevOps Radar Report 2022

    Techstrong Research DevOps Radar Report 2022

    You can’t control the pace of change; instead, consider that we are in a process of reinvention—both with regard to the way organizations use technology and how vendors position their offerings. At the same time, it’s never been more important for IT organizations to have complete visibility into the way technology is used from both a security and operations perspective. 

    This need to embrace reinvention while continuing to have broad and deep insight across all technology platforms led me to create a 2022 DevOps Radar Report. In this article, I highlight three near-term priorities that must be on every technology team’s radar. In addition, I’ll point out some long-range radar trends that should be on your agenda.

    Collision Warning! Your Current Radar View

    API Security

    APIs are the lifeblood of the cloud-native and app-based economies. Increasingly, poor API security across a variety of applications and systems puts your organization at risk. A compromised API or the use of unsupported or outdated APIs can prove to be an easy attack vector for cybercriminals. In addition, API vulnerabilities are calling into question how organizations approach application security and the usefulness of web application firewalls (WAF) and encryption protocols. Therefore, API security is rapidly becoming a top security priority for enterprise security teams and software professionals. 

    Failing to adequately manage the security of APIs creates a host of new challenges and questions that you must consider. For example, who is using which APIs? Are your APIs updated? Did your DevOps team evaluate the security of your APIs during their selection process? Have you formalized the way your organization is evaluating API security?

    It is increasingly clear that an API breach can lead to the downfall of your entire digital software strategy—but it doesn’t have to be this way.

    At Techstrong Research, we segment the market into “pure-play” API security vendors and larger security vendors with specific API security offerings. Our team will be publishing a Market Vista report on the API security landscape soon, so if you want to share your opinion or thoughts, please reach out.

    Below is a brief list of some of the vendors we are tracking in the API security market. Of course, expect consolidation—some of these pure-play vendors will likely be acquired in 2022.

    Pure-play API security vendors we’re tracking include:

    General security vendors with API security offerings that we’re tracking:

    Observability is Evolving to AIOps

    Modern applications are composed of containers and APIs that your organization can’t control, and into which visibility is difficult. Monitoring and application performance management (APM) solutions aren’t new; for many years log vendors built their businesses on collecting log files and sending alerts … so what’s changed?

    First, logs without context are meaningless. You need to understand upstream and downstream dependencies. Additionally, speaking for myself, I’m a mere mortal—if your teams are also made up of mere mortals, there is no way they can ingest, correlate and understand the tsunami of incoming DevOps log data quickly enough to take proactive measures.

    Besides the need to understand context, we are dealing with multiple cloud and on-premises platforms that each have their own logging protocols. Ultimately, the goal of observability and AIOps is to understand what’s happening across and among all these environments and technologies so you can detect and resolve issues as quickly as possible to keep your systems efficient and reliable and your customers happy. 

    Humans are the Biggest Security Vulnerability

    As an industry analyst, I see our clients pouring resources into cybersecurity efforts to prevent zero-day attacks and sophisticated advanced persistent threats (APTs). These threats, while real enough, are mostly external and may not pose as great a threat as many organizations believe. In fact, the vast majority of security vulnerabilities are caused by:

    • Well-meaning employees making innocent mistakes, including:
      • Falling victim to phishing attacks
      • Poor corporate password policies
      • Cloud misconfigurations and open ports
    • Technical debt—relying on older software and hardware that was never designed for a 100% mobile workforce, for example

    The first step in combating this problem is improving security awareness and building a cybersecurity culture. That starts with everyone in your organization understanding that security is a team sport and that it is a 24/7/365 responsibility. Even if you work from home; even when you’re cooking dinner while checking email on your phone, you need to have your “corporate security/Is it safe?” hat on.

    At the same time, machine learning, AI and automation have a role to play. There are emerging offerings that help enforce DevSecOps best practices and help security teams reduce the constant noise so they can focus on the most vital threats.

    Longview Radar: Plan Your Strategy Now

    To support emerging business models, what do DevOps leadership teams need to be thinking about from a long-term perspective?

    • Web3/Web 3.0 and the potential for change to the internet business model. But there is still a ton of opportunity with Web 2.0.
    • How will you support low-code/no-code? As a business model, vendors are selling directly to business units—it’s likely that your IT team has an existing solution to solve the business pain point(s).
    • Packaged software offerings that include blockchain, NFTs and other digital ledger technologies.
    • How to upskill teams, both from a technical perspective and a business perspective.
    • Providing developer teams with the tools they need while establishing guardrails to enforce governance and compliance requirements.
    • How to manage cloud costs in a predictable way no matter how many cloud vendors your organization uses.

    Conclusion: You Can’t Put the Brakes on Change

    Attempting to control change and the speed of reinvention is futile. You need to get comfortable riding the waves of industry change, or you’ll be swept away! Every IT leader needs to learn how to roll with and manage the ebb and flow of business, IT and personnel change.

    The best place to start is by building a successful culture within your organization. Although we often talk about technology-focused solutions to business problems, the first step on this journey doesn’t involve tech at all; it involves helping IT and business teams understand each other’s pain points and learn how they can each support a continual reinvention process.

    I will be tracking these incoming radar targets and other associated trends throughout the year and I look forward to your input. Do you think I missed something? Have a question or want to share what your organization is doing to support the need for continual reinvention? 

    Feel free to engage with me – @DDKirsch, LinkedIn or, of course, email. 

  • A New Language for Digital Transformation

    Charlene O’Hanlon and Rich Nanda discuss a new Deloitte study, “A New Language for Digital Transformation,” which explores why so many transformations fail to deliver concrete impact. The video is below followed by a complete transcript of the conversation.

     

    Announcer: This is Digital Anarchist.

    Charlene O’Hanlon: Welcome back to Techstrong TV. I’m Charlene O’Hanlon and I’m here now with Rich Nanda who is the US monitor practice leader at Deloitte Consulting. Rich, thank you so much for being back on Techstrong TV. It’s great to see you.

    Rich Nanda: Good to be here, Charlene.

    O’Hanlon: Well, I know you spoke with Alan a couple months ago about another report that you guys had out, but I want to talk to you a little bit about the new study that you have called, I believe it’s A New Language for Digital Transformation. Is that the right title?

    Nanda: That’s right, Charlene. Yep.

    O’Hanlon: Excellent. All right, great. So tell me a little bit about this one and what its focus is.

    Nanda: Yeah, so we remain very committed to this idea that digital transformation is in service of business transformation, and in fact, the earlier conversation I had with Alan talked about how it’s even impossible to separate the two in a digital economy that we’re in. So it really is all about how technology is applied to advance the strategies and interests of a company and how a company thinks more broadly about their winning strategies in light of technological innovation.

    And we’re getting a lot of market resonance with that type of thinking and work as companies look to make themselves more sustainable in growing enterprises in an increasingly digital world.

    One of the challenges to making that happen though is technology keeps moving very quickly. Right? And today’s very innovative new technology is tomorrow’s technology death. And how do we give leadership teams a way to have a coordinated and consistent conversation about digital transformation. So that was the impetus of this work and in a world where technology is so essential to how businesses grow and compete, digital transformation as a term in and of itself and all of the underlying technologies within digital transformation, they kind of mean anything to everybody and in that context, how do we help put everyone on the same page?

    O’Hanlon: Well, it’s a very, very interesting question because we have been talking about digital transformation for many, many years, but it’s really only been over the past 18 to 20 months or so that we really have seen it spike and I know that you’re well familiar with the concept and what’s been happening in the market. But, now I feel as though we are not kind of seeing the hangover effects, if you will, of rapid digital transformation among organizations and it’s because maybe what they thought was critical for their business before, maybe turned out not to be so critical for them. Maybe they had to pivot quickly or maybe they just ended up making the wrong decisions about where they wanted to put their priorities in their digital transformation efforts.

    So what are some of the things that you guys have seen then in speaking with clients and folks out in the field about their digital transformation efforts and what was kind of the Achilles heel, if you will, for digital transformation, you know, for those that maybe didn’t go as well.

    Nanda: Yeah. Well, my view is it’s – all of these digital transformations are a work in process and what was a very common refrain throughout 2020 and even the early part of this year was, you know, “We’ve done a decade’s worth of digital transformation in months.” And we do our own survey with Fortune Magazine of CEOs, but there’s many similar surveys that were coming back with this data point that CEOs were saying, 90 percent of CEOs were saying, “We’re doing more digital transformation than ever before.”

    And you know, through the lens of the pandemic and its disruption, virtualization of work for knowledge workers, adding automations for safety purposes into plants and distribution centers, creating more virtual customer interactions like telehealth or like click and collect in retail. I mean, all of those were very real changes that companies were making, some of which were in motion before the pandemic, but clearly, that 90 percent step was the acceleration that happened.

    And now that those projects and investments are a year plus in the making, a new question is arising, which is, well outside of the immediate response, what did we get out of those? What did we learn from them and how do we scale to create the next level of business benefit. And so I think that’s where we are is just a new inflection point. And it’s a work in process. Right? We’re not done with these transformations by any means.

    O’Hanlon: Yeah, I don’t think we’re ever going to be done. It’s kind of like doing DevOps. We talk about DevOps a lot as one of our sites and DevOps is not a one and done thing. You can’t just add a bunch of tools and technologies and say, “That’s it. We’re doing DevOps now.” And I think digital transformation, to your point, is very similar to that and you know, but it also becomes a moving target when it’s kind of always in process.

    So how can an organization understand that it is on the right track and you know, is there a way that business leaders and IT leaders can both kind of, I don’t know, use the same nomenclature or speak the same language, so to speak, and understand what business outcomes they collectively are trying to achieve. I mean, I feel like there’s some sort of disconnect between IT and business a lot of times when we’re talking about digital transformation.

    Nanda: Yeah, absolutely. So I would – I’m going to answer that question but I want to just go back for a second. I’d be remiss if I didn’t talk about the transformation is never done idea, Charlene, that you brought up.

    We actually just published a book which launched last week called the transformation myth and it’s a collaboration between Deloitte, Boston College, and Northwestern and builds on five years of research. But the premise of the book is what we’ve learned through the highly disruptive times that we’re in is that transformation isn’t a one and done event. In fact, it’s in a constant state of adapting to an ever more complex and changing environment and so absolutely, right, transformation is a capability and a muscle, not a finite project or event.

    But in a world where companies are constantly transforming themselves, you’re right, and technology is a key ingredient in that transformation more than ever before, how do business leaders, who are responsible for different units or different functions and they have their own set of priorities, communicate with technology leaders in a way that there’s a shared agenda. And what our research has shown is there’s just a fundamental disconnect in how management teams are able to coordinate and communicate with one another. And it’s very easy to get pulled into a specific disruptive technology and to say, “What’s my cloud strategy? What’s my AI strategy?” Well, actually you probably need to think through what’s our overall strategy and what’s the role of technology in stretching, improving or enhancing in that.

    So what we’re coaching clients on is to think of five digital imperatives, and none of those five actually name a specific technology because the five imperatives allow for multiple technologies individually or collectively to make those imperatives come to life. And I’ll just rattle them off real quickly and then we can talk about them.

    But first imperative is experiences, whether that’s workforce, colleagues, end users and customers. The second is an insights imperative. The third is a platforms imperative and aware and how does computing gets done. The fourth is a connectivity imperative, how do we connect to more players and entities and data in the ecosystem. And the fifth is an integrity imperative, how do we make sure that whatever we’re trying to achieve sustains under stress.

    O’Hanlon: I like that lineup because it does provide a framework, but it does not kind of pigeonhole organizations into using a particular technology, as you said, or even thinking the same way because each organization, their digital transformation efforts are vastly different between different organizations and sometimes even to business units within the organization. It seems like – and we want to make sure that anything that’s happening within an organization as far as improving or enhancing digital transformation efforts isn’t at locker heads with other business units in the organization.

    So you know, I feel like there’s a healthy amount of communication that still needs to happen, even within the organization, not just IT leaders and business leaders, but also kind of that one level down line of business managers or even practitioners to understand that everybody understands what the – I don’t want to say the end state or the end result, because we just said that’s never going to happen, but at least the desired state.

    Nanda: The next interim state.

    O’Hanlon: Exactly. Exactly.

    Nanda: You elocuted on one of our very common fatal flaw or area of inefficiency, which is, look, enterprises are complicated units and what one business unit or function may be trying to optimize for is going to be different than what another business unit may be working on. But at the end of the day, technology is being procured and applied to the organization in a way that should be shared across.

    So how do you build a shared foundation with a common understanding of what that shared foundation can do and then let distinct parts of the businesses get the benefit and the customization they need out of that shared foundation. It’s certainly much easier said than done, but that’s the task at hand and you know, missing on that task, that’s where we’re going to get , well 90 percent of the CEOs said they accelerated, but only half of that would say, “We got the ROI we wanted or some suboptimal outcome.” So that’s the opportunity at hand.

    O’Hanlon: Yeah, well I think that it’s – I think the next 12 months are going to be very telling from an ROI perspective on many of these digital transformation initiatives that are organization that started previous to the pandemic and accelerated or just decided to launch during the pandemic. But I think that there have been a lot of lessons learned along the way and I think we’re nowhere near the point where an organization just kind of can just either take a digital transformation effort and come out unscathed. So with that, I think there’s going to be a lot of bumps and bruises along the way.

    But Rich, thank you so much. We could talk about this forever I feel like, but I do want to thank you for the time that you have spent with me and we’ll definitely circle back another time and continue this discussion. I really do appreciate your time today though.

    Nanda: Thank you for having me Charlene.

    O’Hanlon: All right, great. All right everybody, please stick around. We’ve got lots more tech strong TV coming up, so stay tuned.

    [End of Audio]