Tag: microservices

  • IBM Advances DevOps on the Mainframe

    IBM Advances DevOps on the Mainframe

    IBM has expanded its efforts to bring DevOps best practices to the mainframe by adding automated unit testing capabilities for CICS COBOL programs using Db2 to IBM Developer for z/OS (IDz) V14.2.1. The company is also making an instance of z/OS available within a Docker container that can be deployed on an x86 platform.

    Sanjay Chandru, director for IBM Z DevOps, said both capabilities will play a critical role in enabling IT organizations that have invested in mainframe to be much more agile. The Docker x86 capability will enable developers to build and test applications without requiring access to a mainframe, while IBM’s automated unit testing tools provide a much lighter-weight alternative to previous generations of tools, he said.

    In addition to automating assertions and pass/fail checks, the automated unit testing capability for IDz makes it possible to invoke the tests from within either the tool itself or as part of a continuous integration/continuous delivery (CI/CD) pipeline, Chandru said. DevOps teams also can now store tests in a modern source code management application alongside the code being developed, he added.

    The IBM unit testing tool can now intercept EXEC CICS and EXEC SQL application calls under CICS to allow data capture during a live run. This recorded data can then be used to create additional tests, including negative tests, in a virtual environment without having CICS because tests are now run as a batch job, Chandru said.

    Finally, IBM is also making it possible to export test results in PDF or XML in addition to JUnit and SonarQube formats.

    Chandru said interest in applying best DevOps practices in mainframe environments has increased dramatically as organizations embrace digital business transformation initiatives. Almost invariably, projects access applications that run on mainframe environments but still process most of the data within enterprise IT environments, he noted. Many organizations are now developing microservices-based applications that rely on mainframes at their back end, he added.

    However, given the rate at which those applications are being developed, legacy approaches to building and deploying mainframe applications are not able to keep pace with the rate of innovation now expected, said Chandru. As a result, IBM is encouraging organizations that have mainframes to shift responsibility for building and deploying applications much further to the left, he said.

    Long term, IBM wants to make developing applications for the mainframe “unremarkable” in the sense that tools for building and deploying applications for any platform should work equally well on mainframes, Chandru said, noting that approach will significantly expand the pool of developers that can build applications for the mainframe.

    It may be a while before DevOps best practices are employed pervasively across mainframe environments, many of which are steeped in legacy waterfall approaches to application development. However, there are pockets of IT teams within mainframe environments that are starting to appreciate the need to be able to respond to changing requirements more rapidly. The only issue that remains now is to determine just how deeply best DevOps practices on the mainframe will be embraced.

    — Mike Vizard

  • Four Steps to Implement an Observability Strategy for Microservices

    Four Steps to Implement an Observability Strategy for Microservices

    You’ve finally decided. You’re making the move to microservices and re-architecting your entire infrastructure. Some services will still be on-premises (those databases and their legacy apps are never moving), but a cloud-based microservices architecture will allow your teams to build and bring new products to market faster.

    But how do you handle the complexity that comes with cloud and microservices? You know you need a strategy for monitoring and managing the complex dependencies and ephemeral nature of your new architecture, but you don’t know where to start. What’s more, you don’t want to spend time and money now only to realize a few months down the line that you’re on the wrong road. Your investment needs to be future-proof.

    You need to implement a strategy for observability. Observability goes beyond monitoring to give you greater operational insight, leading to shorter incidents, fewer quality problems, a better product and happier customers. Your company has unique observability needs, which means how you approach your observability strategy will also be unique. As is usually the case, it’s important to start with a roadmap and goals. Based on my experience, the following four things are key to making a considered, comprehensive observability strategy that’s built for the long haul.

    Choose an Observability Platform that Fits Your Future

    Perhaps counter-intuitively, the right platform isn’t necessarily the one that’s the right fit for you today. If you’re investing in new technologies such as microservices, containers and Kubernetes, you’re going to see a significant increase in the scale and ephemerality of your environment. A monitoring platform that may suit your current infrastructure likely won’t be able to keep up and meet your future needs. Instead, consider how your infrastructure will look three, four or even five years down the road, and then select the platform that best fits that long-term strategy. It doesn’t matter if you choose a commercial tool or an open source one: What matters is that you give considered thought to your future infrastructure and choose a platform that can address the future needs of your environment—and protects your investment at the same time.

    Monitor the Metrics that Really Matter

    If you’re still in the early days of your shift from monitoring to observability, you’re likely taking a service-based approach, monitoring specific pieces of your ecosystem with a focus on individual incidents. The real value of observability is the ability to provide visibility into big-picture issues, such as measuring user experience, performance against SLOs and other key metrics important to the business. In modern environments, small upticks in a microservice can cascade into increased latency for an entire product, a specific feature, or even a specific customer. Having an observability platform that measures and collects data across multiple dimensions–e.g. customer/business-specific, application/service specific and infra/host/container specific–will allow you to understand the telemetry in many different ways. The platform should also aggregate the interactions between your services and unlock a wealth of data for engineers to investigate when issues do arise, and provides visibility into the metrics the business cares about most

    Embed Observability into Your Incident Management Process

    Incident management is a hot topic right now. I speak with CTOs across organizations and industries who have fantastic tools that provide detailed telemetry, but everything breaks down when an incident occurs. They need to better embed observability as a part of their incident management process. For example, ask your incident management team how observability helped in a given incident and record those results. This keeps track of the ongoing benefit. Next, ask how observability could be improved to get the team closer to the crucial clues they need during an incident. And finally, make sure to fold these items into your remediation plans so the team has a clear playbook when incidents do occur.

    Establish a Culture of Observability Across Your Organization

    Simply deploying a new technology of any type is not enough. You need to ensure you’ve built the appropriate processes and norms around the new platform to ensure its success—this is especially true with observability. Modern observability platforms can be incredibly powerful in providing insight into the performance of your ecosystem, but without an investment in your organization’s ability to use the platform, you’ll barely scratch the surface of its true value.

    Observability requires ongoing investment and improvement. Start by building a core group of champions, then fold training into onboarding, continuing education or brown-bag sessions. Using subject matter experts to create the content is a good way to get everyone off on the right foot. Use the output from observability tools in company meetings, team syncs or support settings to keep everyone on the same page. This sort of standardization raises the collective skill of the entire organization and demonstrates the value of observability to those who are not already on board.

    Following these four steps will set you off in the right direction on your observability journey. If your organization is like most, you keep an eye on what you think could go wrong. While that’s unquestionably important, a mature observability strategy will give you an insight into previous unknowns and help you more quickly understand why incidents occur. And as you continue on your observability journey and your understanding of what and why things break improves, you’ll be able to implement increasingly automated and effective performance improvements that impact your company’s bottom line.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Arijit Mukherji

  • The New Era of Kubernetes, With StackRox

    The New Era of Kubernetes, With StackRox

    Orchestrators are becoming the operating systems of cloud for the future. Which one do you think has become the dominant one? Ali Golshan, co-founder and CTO of StackRox, placed his bet on Kubernetes right from the start.

    StackRox is a Kubernetes-native security platform that helps DevOps and security teams operationalize security, providing richer context, native enforcement and continuous hardening.

    During this interview with MediaOps founder and editor in chief Alan Shimel, Ali discusses the adoption of Kubernetes and its prevalence today. More companies are realizing they can’t use traditional security. The tooling has to be native to the infrastructure they’re using, it must integrate into the build and the deployment. And Kubernetes is the best solution available, he said.

    Check out the interview below to learn more about microservices, containers and Kubernetes.

    — Veronica Haggar

  • Understanding and Implementing the APM Puzzle – Performance and Availability

    Understanding and Implementing the APM Puzzle – Performance and Availability

    While every organization is unique, there’s one universal goal everyone can get behind—creating and delivering an exceptional end-user experience. For both classic IT organizations and companies built in the age of cloud, delivering continuous availability and appropriate application performance is key.

    Although digital transformation has become a buzzword some would say is meaningless, the idea of digitizing a traditional company and building new businesses whose foundations are established upon the latest web technologies is critical in today’s IT and non-IT organizations. Think about the prevalence of cloud migration efforts during the past several years. Traditional organizations typically prioritize on-premises applications with increasing quantities of hybrid applications. But, because they aren’t yet fully transitioned to cloud—whether IaaS, PaaS or SaaS—their IT organizations need to live in both universes.

    Monitoring these environments at both the infrastructure and application tiers and across each stage in this transition requires support of a full stack of tools to cover web uptime, user experience, transaction monitoring, application tracing, log analysis and appropriate infrastructure monitoring. That said, modern organizations that have fully embraced cloud and leverage modern microservice architectures have similar challenges, but the exact same level of monitoring visibility requirement.

    Whether public, private, hybrid or multi-cloud, nearly every organization has moved to the cloud in some capacity. Regardless of what the company produces or the services IT provides, it must maintain uptime, availability and seamless performance to create and continuously deliver a user experience rivaling competitors and exceeding user expectations.

    Because let’s face it, even though every business is different and virtually every market is saturated, consumers and B2B companies have more options than ever. Without delivering a solid end-user experience, there’s an ever-increasing plethora of alternative vendors and providers from which customers can choose.

    Public Cloud Platforms for Classic IT Organizations and the Cloud Generation

    Let’s explore a few differences between how traditional IT organizations and cloud-era companies interact with the cloud. At a high level, Azure is a natural choice for IT companies with significant investments in apps traditionally acquired (not built) by the company and managed by their IT team, that are now tasked with digitizing their business by leveraging public cloud platforms. These types of companies often have Microsoft Office, Microsoft Exchange and other Microsoft products already implemented on-premises, and Infrastructure-as-a-Service (IaaS) or Platform-as-a-Service (PaaS) solutions as well. If they’re now adding a public cloud platform to their mix, staff expertise and solution familiarity make adopting Microsoft Azure a natural next step. Microsoft has long recognized the need to make these types of transitions and mixtures easier, demonstrated by its Office365 suite (as an example).

    On the flip side, companies that were born fully in the cloud, (i.e., relatively newer organizations without a legacy anything on-premises, with respect to IT infrastructure) will likely have a higher propensity to choose a provider such as AWS or Google Cloud even though Microsoft, Oracle and others are certainly competing there as well. So, it’s not a matter of one being intrinsically better or more fully-featured, but about which is the best fit for the organization and its priorities.

    At the end of the day, however—regardless of organization type or public cloud platform implemented—every company needs monitoring tools and solutions that keep applications up, running and performing seamlessly. With an integrated set of simple, easy-to-use, quick to value and powerful solutions, organizations can achieve truly proactive lifecycle assurance of application availability and performance.

    Uptime and Seamless Performance: Putting Together the APM Puzzle Using All the Pieces

    Each and every piece of the APM puzzle must be incorporated to achieve full-stack visibility and ultimately top performance: user experience, metrics, traces and logs. Having a log management solution monitoring availability, enables proactivity and enables IT to react quickly to help identify and remediate problems is paramount—it’s table stakes that everything be available. After all, if a website or page isn’t accessible, business transactions cannot be processed and that business is effectively down.

    Creating and maintaining a healthy application involves not only ensuring it’s functionally available to users; it must also be performing appropriately—continuously delivering both a reasonably responsive user experience and supporting the required volume of transactional work. This means a complete view into all aspects of performance—from the website and webpages all the way into and across all relevant application components and their associated infrastructure—be proactively visible and monitored.

    There is thus a natural and increasingly urgent workflow affinity between logs and APM—across the development lifecycle. When errors occur, it’s critical to understand, precisely and immediately, where are the impacts on service performance, or if there even are any impacts. Conversely, when application performance issues arise, it’s critical to immediately know exactly which errors—across the complex and constantly changing infrastructure and application stack—are directly related to the problem at hand.

    Without this bi-directional workflow integration, not only can application performance and availability not be managed proactively, but any issues with application service availability and performance will take far longer to diagnose and repair—seriously impacting the business bottom line.

    Just because everything is available doesn’t necessarily mean it’s appropriately performing for the end user trying to use the application.

    With all this in mind, it’s paramount to implement powerful, easy-to-use solutions that’ll achieve integrated application performance and availability management for any type of organization operating on-premises and/or cloud-based applications across all cloud environments.

    Conclusion

    While traditional IT organizations and cloud-only companies are different in many ways, providing exceptional end-user experience and achieving seamless availability and performance (no matter what) is a common and increasingly critical business goal. To achieve business success, organizations should choose a complete suite of simple, powerful and integrated solutions to optimize and manage their cloud-hosted applications and platforms. Anything less leaves the APM puzzle unsolved.

    — David Wagner

  • How AI and Microservices Create a Reliable Enterprise of the Future

    How AI and Microservices Create a Reliable Enterprise of the Future

    The Rise of Microservices

    Enterprise adoption of microservices is continuing to rise. Its popularity is so strong that 86% of development professionals internationally expect microservices to become the default application architecture within the next five years. Looking out even longer, nearly all professionals see microservices becoming their company’s default application architecture.

    At its core, a microservice approach centers on the idea of breaking up complex enterprise software into smaller, more manageable pieces, containing everything from the operating system to the platform to the framework to run time and dependencies, packaged as one unit of execution.

    By dividing an application into smaller stand-alone services, each performing a single function and communicating over the network to work together, microservices offer increased modularity and make applications easier to scale and faster to develop. In a world of ever-increasing apps, websites and digital experiences, there are immense benefits to deploying microservices.

    However, the use of microservices is no silver bullet and, for all their benefits, they have their own limitations and challenges. When it comes to deploying microservices, scale, complexity and constant change are the new realities. Microservices architecture introduces complexity with respect to network latency, network communication, load balancing, fault tolerance and message formats. With great flexibility also comes a higher risk of something slipping through the cracks. Managing many services requires understanding deep structures, dependency graphs and more.

    Process scalability is another challenge. An enterprise can run one cloud-based service with relative ease, but simultaneously running dozens of services across multiple clouds quickly becomes a complicated juggling act. In fact, with all the moving parts that come with microservices, it is becoming increasingly difficult to manage these processes manually.

    No wonder that, along with the rise of microservices, we have seen the emergence of auto-remediation/self-healing capabilities. To the untrained eye, the terms auto-remediation and self-healing would seem to be the answer, but don’t be fooled. Many of these features, although making the management of microservices easier, use static thresholds for data points such as waiting time, throughput, message queue size and more. When the thresholds are passed, the system will correct or self-heal as necessary. Although helpful, they’re not necessarily smart or intelligent—and that is where AI can help.

    Advanced Self-Healing and Self-Defense

    AI can help solve some of the hardest problems facing microservices today. Below are a few achievements we’re already seeing AI accomplish:

    • Load Prediction: Understanding the load on the system and acting on it before it happens will allow systems to provision more resources before they’re needed. Provision of resources is not just limited to the network and number of tasks running; AI can trigger customer support representatives to be on hand when—and only when—needed.
    • Decay Detection: Anomaly detection is built into a lot of monitoring services and is efficient at detecting spikes, loads and abnormal behaviors; however, detecting a service decay, even gradual or subtle, is difficult. AI can help systems recognize whether services are reacting differently over time and what the reasons are for this decay. It also has the potential to be more effective in identifying bugs based on studying clusters of microservices having continuous issues.
    • Resource Planning: As the scale and complexity of microservices grows, so does the use of the cloud. The ability to plan ahead using smart resource management could save significant costs while maintaining a stable and robust service.
    • Security: Security is already leveraging AI in many places by discovering attack patterns based on known behaviors. Leveraging these capabilities at the network and database level can improve security for actions done by an authorized person. If you can understand the usage patterns and act on them, you can define a more secure system for all users.

    Benefits aside, using AI is not without pitfalls. For example, despite all its potential, the so-called state-of-the-art AI models are still quite primitive when compared to what they have the potential to achieve. Another issue is how to manage the possibility of bias creeping into AI models to avoid unintended consequences. Technology professionals are already working on ways to solve these complications. However, it will take time to develop the right models, data sets and algorithms.

    The Future

    If the future of application architecture is truly to be dominated by the ever-increasing use of microservices, then those architectures will need to also be dominated by AI. The reality is microservices are simply becoming far too complex for humans to manage on their own effectively. Because of the dynamic nature of their structure, their complex dependencies and their sheer scale, machine learning must be applied to assist with monitoring and management tasks. AI is best suited to meet this challenge and tackle it head on.

    — Martin Henley

  • Should Your Company Use DBaaS?

    Should Your Company Use DBaaS?

    From SaaS to IaaS, companies are rapidly moving to the cloud to gain huge agility and cost benefits. So, is it time for your company to take advantage of database as a service (DBaaS)? Here’s a high-level discussion to help you along your decision path.

    First, it’s important to distinguish DBaaS from simply running a database on a cloud-based server, such as Amazon AWS or Microsoft Azure. While you can certainly gain some cost and agility benefits from running your database on a virtual machine, you’ll still need to provision and maintain the database, that is, you will need server operations expertise.

    With DBaaS, the cloud provider also provisions and maintains the database, eliminating the need for your organization to maintain server operations expertise in-house. DBaaS manages the entire environment—physical and virtual hardware, operating system, networking, replication configuration, etc.—so you can stay focused on software development. With the click of a button you can set up the database and then connect your application with a simple API call. And you’re ready to go.

    The speed and cost advantages of this approach can be huge, but there are also some limitations, so it’s important to assess whether your company’s resources and your project’s requirements align with the current capabilities of the various DBaaS offerings.

    Reasons to Use DBaaS

    Lack of Expertise: As suggested above, if your technical team is mainly composed of software developers who won’t be able to manage the complexity of provisioning a database, you should consider DBaaS. In addition to handling the management of the database, the DBaaS provider will offer additional services, such as automatic backups of your data. In this worry-free environment, you can focus on optimizing your software instead of constantly worrying if the database is functioning properly.

    Short-Lived Databases: If you need databases to serve as back ends for continuous integration testing, DBaaS will allow you to rapidly provision the databases, populate them with test data and then delete them when they are no longer needed. Having the database provisioned for you makes it far faster and simpler to build the required automation for the testing environment.

    A Microservices Design: DBaaS can be particularly helpful, even in a production environment, if you are using a microservices design composed of a very large number of databases. Even if you have the internal expertise, you may not want to invest the time and effort in deploying all those databases. DBaaS can get you into production significantly faster.

    Reasons Not to Use DBaaS

    While the above benefits are appealing, you likely won’t want to use DBaaS in the following scenarios.

    Database-Centric Applications with Complex Topologies: To ensure ease of deployment, DBaaS providers limit the ability to deploy complex environment topologies. This reduces the flexibility DBaaS customers have. For example, let’s say that for disaster recovery, you have a primary synchronous replication cluster in one region and a secondary synchronous replication cluster in a different region, with an asynchronous relationship between them. This relatively complex topology is outside the scope of most DBaaS offerings.

    IO-Bound Workloads: If your database has IO-bound workloads, you may need very powerful hardware, including high-end CPUs, terabytes of memory and very fast storage. In this case, you may not find a DBaaS provider that offers a configuration that will meet your needs.

    Understand Your Options

    If your database requirements align with the capabilities of DBaaS, you now have the ability to eliminate significant operational complexity and develop, test and deliver your applications faster and at a lower total cost. However, make sure you spend time carefully investigating today’s DBaaS offerings, including Amazon RDS, Google Cloud SQL and Azure SQL Database, which all have different features and focus, including deployment models, performance trade-offs, instance types and more.

    If your needs don’t fit current DBaaS offerings, you’ll need to provision your databases yourself. If you don’t have the expertise in-house and can’t afford new hires, a database consultant may be a cost-effective strategy for getting the support you need.

    — Tyler Duzan

  • DevOps Chat: Splunk Moves Into Microservices With Omnition Buy

    DevOps Chat: Splunk Moves Into Microservices With Omnition Buy

    Swiftly after announcing its acquisition of SignalFx, Splunk is vaulting into microservices tracing by announcing its intention to acquire Omnition. Tech companies are rapidly making acquisitions to strengthen their position in the DevOps and contemporary cloud-native software stack.

    Rick Fitz, SVP and GM of Splunk’s IT Markets Group, joins DevOps Chat to share with us the drivers behind Splunk’s move into microservices and service mesh tracing. Information about Omnition is in short supply as Omnition’s been in stealth, racing to develop a product to address the observability needs of DevOps teams. Omnition has received some notice through its contributions to OpenCensus open source, now being merged into OpenTracing.

    In addition to this episode of DevOps Chat, check out Mike Vizard’s article about the Omnition announcement.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Rick Fitz, SVP and GM of the IT Markets Group at Splunk. And tailoring onto some recent news, the topic is about Splunk’s intention to acquire Omnition. They announced that on September 4th. Rick, welcome to DevOps Chat.

    Rick Fitz: Thanks, Mitch. Happy to be here.

    Ashley: Great to have you on. Would you start just by introducing yourself, tell us a little bit about what you do? And I’m sure most people know Splunk, but maybe a sentence or two about Splunk.

    Fitz:  Sure. A little bit about me, I’ve been building commercial software my entire career, and started out as a developer working for companies that were development oriented, and then the last 15 or 20 years, I’ve been working on just developing software for IT operations and application development teams in a commercial fashion.

    And in my new role now, I’m here as a General Manager, so I’m an executive here at Splunk, responsible for our strategy and vision of what we’re doing in the company. For those who don’t know Splunk—shame on you, darn it.

    Ashley: [Laughter]

    Fitz:  [Laughter] But let me tell you a little bit about the company. We are the company that actually built and invented, if you will, the ability to index logs at scale. And it made it really easy for the IT practitioners of the world to search that data and find, through an investigative lens, find the actual answer to those murky problems that are always out there. And so, the company is roughly 5,000 employees now, and growing very rapidly. So, we’re headquartered in California.

    Ashley: Well, just a little bit of trivia. I can’t claim credit for this, but I came across Splunk in probably 2006 or so at, I think it was an RSA conference. Tiny little booth, great ideas. Like, this is a cool idea. And of course, the company’s done really well, and I later became a customer of Splunk. So, congratulations on all the success and glad to see that you’re there, too, of course. Well, let’s talk—

    Fitz: Well, I thank you for being a customer.

    Ashley: Oh, absolutely, absolutely. [Laughter] So, let’s talk about Omnition. A lot of people may not know about them. Maybe they do, if they’re open in the—or involved in the OpenCensus, OpenTracing, OpenTelemetry projects, if I can say that right.

    Fitz: Mm-hmm.

    Ashley: They may know them from that, but they’re in ________ so there hasn’t been too much about Omnition. Tell us about that company.

    Fitz: Yeah. The—first, I’ll back up a little bit and kind of let you know why we even picked up a company called Omnition that no one really knows about. [Laughter]

    Ashley: Sure, that’s a good question, too.

    Fitz: The reality is that, in these large, cloud native worlds that a lot of us are starting to develop in, all kinds of things are changing. The things that we build on, the infrastructure we build on, the compute surface, the storage surface, there’s all these things that are now services that are available to us to leverage as application developers.

    And the other thing that’s changing pretty dramatically is just the way we actually build applications. The way we try to attempt to continuously integrate them, continuously deliver them. And perhaps one of the most profound things that’s occurred is that developers are now being asked to kinda own their code and they’re being asked to be on call or being asked to resolve issues.

    And so, if you will, they’re starting to become, as your website suggests, DevOps professionals.

    Ashley: A la DevOps.

    Fitz: Yeah. [Laughter] These trends start to kind of cause a paradigm shift—well, they have, actually, created a paradigm shift in the way you monitor. So much so that, probably over the last couple of years, DevOps practitioners have been talking about monitoring as—they’ve labeled it as a new world called observability.

    Ashley: Mm-hmm.

    Fitz: You know, I’ve been here around enough to know it’s simply monitoring. But I think what they’re trying to point out is that you need to observe the behavior of the data from the systems in order to make your lives easier. And that data comes in the form of logs, which is what Splunk has been known for a long time. It comes in the form of digital exhaust coming from monitoring tools in the form of metrics, which is really important.

    And then the last thing—and if you’re an application developer, I think we can all kinda relate to this—is the traces, the traces that actually come from the application code itself being executed are really great uses of good information.

    But all three of those things combined, the logs tell you kinda the root cause, the metrics tell you kind of what’s going on—is there a measurement that’s out of whack? Do I need to do something proactively to cause something to remove an error?

    And then the traces are really good for that logical layer—that logical layer telling you where to look. Do I have a backing problem? Do I have a code problem? Is it my problem, or is it a front end problem? And that kind of isolation is really important to trace it.

    So, that leads me to answer your question is that, you know, Omnition. Omnition was actually founded in 2018. The team is very small. They were in stealth mode, meaning they were building an application that was focused on tracing, and very specifically, they had a couple tenets in mind when they wanted to do this. They wanted to leverage open source. So, you mentioned that they’re big open source contributors, specifically to the OpenTelemetry project.

    And the other thing that they wanted to do is, they wanted to build this logical topology model that would allow you as a practitioner to isolate where a problem resides. And that was a pretty—it is a pretty novel way of looking at this particular problem. And it’s important, because having a thousand traces isn’t terribly intuitive or useful for a developer.

    Ashley: [Laughter]

    Fitz: But being able to isolate that it’s a front end problem so I can go talk to the guys that are in charge of that—or maybe it’s my logic that’s causing it, but maybe it’s a network issue, firewall issue or something like that. Or maybe it’s outside my firewall and I’m dealing with some latency issues from the world around us.

    Ashley: Mm-hmm.

    Fitz: But you need to be able to isolate that problem so you can solve it. So, long winded answer is, these guys, this team really figured out how to build this logical topology sitting on top of this trace data, leveraging open source—so, pretty darn powerful.

    Ashley: What I was really excited about with this announcement is, one of the things that I talk with companies about and work with them oftentimes is what DevOps, in this fundamental way that we’re creating more cloud native applications, how this really changed the way organizations work as well as how we create software, which I know you speak a lot about.

    And in some ways, what we’re doing is through this kinda granularization of functionality into containers, microservices, mesh—service mesh—it’s very interesting, because you can do lots of great things with it. But it makes the complexity of operating and monitoring—as you say, observability—even more difficult. So, that’s created this whole new cottage area, if you will, which is what Omnition went about, and actually some of the, they’ve had some developers who came over from Lyft, I think, went over to Omnition to help solve this problem.

    So, it’s fascinating to me to see Splunk bring this, this quickly, into your kinda product portfolio of companies, or at least that’s what we expect to happen with the acquisition, that you’re jumping right into service mesh, microservices, and observability, the monitoring of that. So, it seems like it’s a natural fit—maybe, you know, sooner than I expected it to happen, actually.

    Fitz: Here’s what’s interesting. I mean, we have the luxury of a lot of—you know, being around for a while and talking to a lot of our large enterprise customers that are going through this digital experience. You know, they’ve done their lift and shift, they’ve moved to kinda the lift, shift, and augment, and now they’re building a whole new series of cloud native digital services. So, they’re building in this new cloud native way. And when you start to talk to them, they recognize the problems, and they realize there has to be a way of doing this.

    And what we’ve found was, a number of them were trying to build it on their own, or they cobbled together a prototype that actually would kind of get ‘em there, give them some visibility. And then having a lot of those customers kind of advise us—because they’re very large customers at Splunk because of the fact that logs are a critical component of this strategy. But they were building the rest on the side, and in some cases, you know, using other companies to try to do it.

    And we just quickly realized that this is an opportunity for some of our largest customers, for us to come in and help them with this very critical issue and build alongside them as we move forward.

    So, yeah, we recognize that certainly the tracing part of this world is pretty new, but we think it’s the right approach, it’s the right answer to a long-standing problem, and I think the application architectures are at a stage in this cloud native world where this is perhaps the only way that this is gonna be accomplished. So, that’s why it was so strategic for us to do this.

    Ashley: You know, like, observability kind of being replaced for the term monitoring, tracing is also used—you used the word “also”—as kind of a new term in this service mesh, microservice world. Does it have a fundamentally different meaning to you as to what log analysis and things like that—is it substantially different or is it just an extension of what we’ve been doing in a non-container, non-microservice world?

    Fitz: Well, the only analogy is, it tends to be text, [Laughter] and you have to put it somewhere. And actually, some of our customers were putting it in the log and then extracting it, but that’s useful if you’re looking for one specific trace, but if you can imagine some of these applications are throwing up hundreds of thousands of traces a second, and sifting through that, while you can search through it, it’s great, but you really do need some analytics on top of it to organize it in a way that creates useful information. And that, I think, is again what Omnition has done.

    You know, answering the question, “Is this different from the old approach?” You know, I had the opportunity to work with an early Wily team. They had been acquired by CA Technologies, and I got to work with the team, which is an APM company. And the team actually invented bicode instrumentation, which is a way of doing instrumentation of the application on the fly. And it was very novel, because at the time, the operations teams were responsible for monitoring and the developers weren’t. So, the only way they could get their developer team to get visibility into the application—because they couldn’t tell their developers to actually put stuff into the logs.

    Ashley: Mm-hmm.

    Fitz: Well, they could ask. [Laughter]

    Ashley: [Laughter]

    Fitz: But they just couldn’t demand.

    Ashley: They might have ________.

    Fitz: Exactly. [Laughter] You know, us developers, how we are. And so the funny, interesting thing about that is, we tended to sell to the operations teams, so they could get that visibility into their application. In the open tracing world, because the onus, and it gets back to this DevOps ________, the onus is actually upon either an SRE function or, if you will, a DevOps function to establish the standards and policies. Those policies have been enforced by that team, and therefore, the developers, before they can actually bring product into production or bring code into production, there’s ________. And now, all of a sudden, you’re getting a lot more visibility and a lot more fidelity inside the code by that enforcement.

    And then, of course, open tracing is now on to its own standard, so you’ve got a standard to kinda drive. Before, there was no real standard, so you were just putting stuff into a log. And therefore, it’s hard for a vendor to look at it and develop an application to give you visibility into it.

    So, that’s definitely some of the big shifts that have caused this new paradigm to actually emerge, which is pretty awesome.

    Ashley: I think I saw in a blog post either on your site or Omnition’s that their investment and contributions to OpenTracing is something you’re likely to continue and support and want that to continue, is that correct?

    Fitz: Oh, absolutely. Absolutely. We’ve actually been, at Splunk, probably for the last four or five years, pretty definitely contributing to open source more, leveraging open source. We’ve been kind of on that bandwagon for quite some time. But this one, it makes a ton of sense. Both the OpenCensus and OpenTracing have now converged into OpenTelemetry. It makes a lot of sense. And I think that this is definitely where the world is—where it’s headed. I think it’s long overdue, actually. [Laughter] I’m glad to see these things kinda moving forward.

    Ashley: Given the players involved, I think if I recall right, OpenCensus was started by Google, but quickly followed by Microsoft and Dynatrace and Omnition—

    Fitz: Yeah.

    Ashley: – I think was part of this effort, too. So, it’s got some important names behind it.

    Fitz: Yeah, and most of the monitoring companies out there that are touching on applications are participating. So, I firmly believe it will take on as a standard. I think that’s pretty clear.

    Ashley: As you were considering an acquisition like Omnition, what were you hearing from your customers that led you to say, “We need to go find a company” or, “We found somebody like this. This would be a great fit for some of the problems and needs requirements that’s awesome we’re hearing from customers”? What was it that’s behind that, what you’re hearing from customers?

    Fitz: Well, there’s the big part of kind of the equation was this idea that we can use OpenTelemetry and spit this data into a log. But that’s good. I mean, that’s a great first step. I can search for something and that’s a fantastic, great step.

     But very quickly, the customers that we were dealing with at scale, they were saying, “You know, what’s interesting is that all this data—I have the data, but I can’t find any useful information out of the data, you know? I’m struggling with that.” And so, you know, we were in there building, on top of Splunk, the ability to model it and do different things. And we realized there’s the answer. The answer is to develop some form of analytics on top of this big, rich set of data that provides you really useful insight.

    And then, from my APM experience and FHIR experience, you know, the whole idea was having kind of a logical topology that represents the application, and I mentioned some of those words meaning back ends and front ends on the application itself. So, once you have that meta model in your mind and can decorate it with trace information, it becomes incredibly powerful. And that’s—when I broach the subject with our customer and said, “Is that really what you’re looking for?” they said yes.

    And so, we’re surveying the market and seeing is there anything out there, and then Omnition popped up, and it was like—wow, it’s a good day. [Laughter] It’s a perfect day for us, because we would’ve had to build this, and I think this team, with the expertise they have and the smarts they have is gonna be a welcome addition to the team and help us do it for us.

    Ashley: They do. They do have some great people. Now, Omnition, as I understand it, they describe themselves as a SaaS company. I assume this is a SaaS service that they’ve been building. Is it something new for Splunk in terms of a SaaS offering, or does this fit in well with other things that you’re doing?

    Fitz: No, it fits in very well. You know, SaaS grows from a business perspective as a very high growth business for us. We tend to, because data has gravity, [Laughter] we tend to have our software where the data resides. But more of that data is starting to reside in the cloud, so you know you’re starting to see people, as I mentioned, lift and shift or lift and shift and augment or building kind of in a cloud native way.

    So, we’re definitely—we’re part of that trend as well, and we think it’s the smart thing for all of us to get there. So, yeah, we are definitely gonna be SaaS on this particular offer, for sure.

    Ashley: Well, that makes sense, too, doing cloud native if you’re doing microservices, service mesh—more than likely, that’s gonna be stuff in the cloud. So, having Omnition there as well, that seems like the place to be, the right place to be.

    Fitz: Yeah. You know, it’s interesting, I was telling some sales reps yesterday, we were talking and I said, “You know, I contrast the conversation that I had with somebody who owns the data center with somebody who’s working in a cloud native way, and the vocabulary is completely different.” [Laughter] You know?

    Ashley: [Laughter]

    Fitz: Nobody says on premise or cloud—they just don’t think that way. They just assume that it is all cloud, you know? Whereas if you talk to somebody that’s still in a data center, they wanna know where the data is, where do I stack it, where do I rack it, where do I plug it in?

    And so, there’s definitely a difference in that cloud native world, the way people think.

    Ashley: Well, I’ve often had to believe, maybe learned over time, is that you can tell who drew the picture of a diagram on the whiteboard. Whatever is at the center is the data—if it’s the data center people who drew it, if it’s the cloud, it’s the cloud people.

    Fitz: Yeah.

    Ashley: But it’s interesting the transition we’re making with multiple companies investing in cloud management platforms, even down to storage providers and VMware and others. You know, I think eventually we’ll stop talking about hybrid. Everything’s a cloud, whether it’s just in your cloud or somebody else’s cloud and it’ll be managed much the same way. That’s where we’re headed, anyway.

    Fitz: Yeah, and I kinda share that point of view. I think, organizationally, we have to kind of force some of that standardization of vocabulary just to make our lives work. [Laughter] I think it’s gonna get—

    Ashley: Well, it’s also—yeah. [Laughter] I also think you have to do it from a cost standpoint, right? Complexity, managing a physical data center one way and then all these different clouds a different way. So, anyway, a whole ‘nother topic for another time.

    Fitz: Yeah.

    Ashley: We have just a little bit of time left—is there any message that you wanna make sure that gets out to listeners, to customers, future customers about the path that Omnition sets you down or other things about this pending acquisition that we wanna make sure folks know?

    Fitz: Yeah, let me just kinda share a couple things. One is, as I opened with, I think this world of observability is certainly all about having logs as well as metrics as well as traces. Just a couple weeks ago, we actually also announced our intent to acquire SignalFx, so we’re bringing in some of that metric capability. We’ve been known for years to be the log company, and then of course, Omnition is helping us with our tracing capability.

    And so, I think the combo is gonna be pretty darn powerful. I’d encourage your listeners, if they get a chance, if they wanna join us in Las Vegas this year at our .conf, which is our conference. We’ll be talking a lot about what we’re doing there and getting everybody up to speed. And if you can’t attend, all that stuff is posted online, too. You can check us out there, as well.

    Ashley: Yeah, there are definitely some great videos out there, too. Well, I wish you all the best with the acquisition and future business with Splunk. I just want to say thank you—Splunk is a great product, and when I had the opportunity to introduce it in organizations that I was running, all positives. So, it made a big difference in our world, and I think your move into observability around microservices, et cetera, is fantastic, and we appreciate you taking those steps.

    Fitz: Well, thank you. Thank you, Mitch, and thank you to all the listeners for your kind words. I’m sure you’re gonna share with me online later on.

    Ashley: Well, thank you, Rick—Rick Fitz, SAP and GM of the IT Markets Group at Splunk for joining us on the podcast today. And, of course, I’d like to thank you, our listeners, for joining us as well. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • Atomist Takes on Application Drift Management

    Atomist Takes on Application Drift Management

    Atomist today announced it is extending the capabilities of its software delivery automation platform to include drift management tools that make it easier to identify changes to code.

    Now in beta, that capability is based on an open source project dubbed Org Visualizer, which makes it possible to clone an entire project hosted in a GitHub repository via a single click and then visually inspect it.

    DevOps teams also can leverage a built-in Policy Manager to capture and track changes in code, define custom policies that automatically apply updates and automated actions and generate progress reports showing how close they are to achieving a target policy goal.

    Atomist CEO Rod Johnson said the reporting tools provide a visual representation of what’s occurring within an organization’s codebase to make it easier to identify both overly complex dependencies and vulnerabilities.

    The drift management tools are built on the software delivery machine (SDM) concept that lies at the heart of the company’s core platform, Johnson said. The Atomist platform is based on a domain model for software delivery constructed around an application programming interface (API) server and GraphQL, an open source data query and manipulation language. That approach eliminates the need to master, for example, complex YAML files to deliver software. The addition of the visualization tools not only make it easier to see what’s going on in the development environments, but they also make it easier to identify areas where technical debt in the form of bugs and vulnerabilities is building within an application development project, he noted.

    The sooner those issues are addressed, the more probable it becomes that DevOps teams will deploy reliable, secure code, rather than needing to update it or roll back the entire application, Johnson added.

    Although the Atomist platform is capable of working in any application environment, there’s a high correlation between organizations that have embraced microservices-based on containers and organizations looking to automate software delivery using the Atomist platform, Johnson said. Organizations that embrace microservices based on containers typically have a frequent need to update codebases in production environments, he noted, adding many organizations don’t know the impact that microservices updates have on the rest of the production environment.

    In general, there’s been a lot of DevOps progress when it comes to automating continuous integration within the context of application development project. However, automating the delivery of software has proven to be a more elusive goal. As the rate and amount of code being developed continues to accelerate, it’s now only a matter of time before software delivery automation becomes a more pressing issue. Manual deployment processes prone to errors only serve to aggravate application development and deployment backlog at a time when business leaders are demanding IT teams become more agile.

    At the very least, tools that enable DevOps teams to visualize the scope of the challenge ahead should help frame a realistic conversation about what’s truly achievable, given the current state of the codebase.

    — Mike Vizard

  • FaaS is Key to DevOps Efficiency

    FaaS is Key to DevOps Efficiency

    When AWS announced Lambda–a serverless Function-as-a-Service (FaaS) technology offering–the idea of encapsulating a specific task into a function that resides in the cloud was introduced into mainstream access.

    Now, with the rising popularity of microservices, DevOps is waking up the benefits of FaaS where it is used to build and maintain enterprise applications in agile environments. The move to serverless architecture using FaaS is one organizations are now increasingly likely to investigate in 2019.

    Given these industry realities, we need to ask ourselves what place will FaaS take in contemporary computing environments and how will its core efficiency proposition enable DevOps to flourish and improve experiences for users at every level?

    Back to Focus

    First let’s remind ourselves what any FaaS platform really does. It allows us to focus on developing and executing business logic because server provisioning and management is handled automatically at the backend. Developers can deploy applications into a space with zero server administration, yet with the ability to enjoy high availability and high scalability.

    The impact for DevOps is immediately apparent.

    Developers are able to work in a zone where they are essentially abstracted away from the servers their applications live and breath on. The services developers draw upon are event-driven and eminently scalable. Even if they have to scale by some massively parallel level of magnitude, server-side service optimization is handled at the backend by the FaaS vendor.

    At the same time, the cost structure is shifted and operations staff are able to oversee compute billing models based on actual execution of functions, as opposed to being dependent on the physical size of a pre-provisioned cloud server established at best guess size and core optimization parameters for compute, I/O, storage, analytics and so on.

    Speedier Implementation

    If we have so far looked at the FaaS efficiencies that reside at the backend server-side management element of the equation, let us also turn our attention toward the way FaaS allows developers to reduce the amount of time it takes to deploy code in a new environment.

    Adopting a FaaS-centric approach to application architectures allows the developer team to encapsulate specific software tasks into functions, hence the name. For a mortgage calculation application, for example, we can encapsulate functions such as interest rate calculations, payments, length of contract etc., and then place those functions in the cloud on a FaaS platform. The FaaS provider is responsible for the hosting of that function and also looks after the heavy lifting associated with availability and redundancy.

    The benefit to developers is a very rapid environment for deploying new code, getting feedback and iterating. The operations benefit is one of hosted happiness as the FaaS provider shoulders a significant administrative burden.

    FaaS and microservices are now increasingly viable options in any modern technology architecture and it’s important to distinguish between the two.

    Microservices are made up of self-contained elements of business logic designed to perform a very specific job. They are optimized for their single responsibility and can communicate with other services via application programming interfaces (APIs). Further, they can be developed, deployed and scaled independently without impacting other services.

    A FaaS-based approach is well-suited for transactional workloads where code is run periodically. This is also a technology that is quicker to establish, as and when needed. A FaaS function might also make a call to other application logic that (in the case of our mortgage example) calculates interest rate and so on.

    FaaS Challenges

    Like any still-nascent technology, FaaS has its functionality flaws and challenges. The automated nature of foundational provisioning in FaaS is great news, but it’s not a panacea.

    Why? For one, DevOps teams will have limits on the debugging capabilities for applications that run on FaaS DNA. Also, functions are instantiated and then de-instantiated as needed, which requires time, especially for a cold start. This process can cause unwanted delays in time-sensitive operations. The transient nature of FaaS also impedes state preservation among dependent functions, which requires careful design considerations.

    FaaS is a place where the burden of server resources control has been shifted. But there’s no such thing as a free lunch and this means DevOps won’t be able to interject some level of application monitoring function at the server level itself. You’ll need to know more about your FaaS-based application before you FaaS it up.

    We must also remember for any distributed software architecture, there’s an up-front responsibility to design to accommodate the limitations and increasing options available in modern services.

    The FaaS Road Ahead

    Examples of FaaS now extend beyond AWS Lambda, we can also look to Microsoft for Azure Functions, Google for Cloud Functions, IBM OpenWhisk, Oracle Functions, Fn Project and IronFunctions with its Iron.io platform.

    This sector of the software landscape is guaranteed to grow over the coming years. FaaS can be an appropriate option in an overall software architecture, but there are specific limitations, so choose wisely. Observing the evolution of FaaS over the coming years will be a fascinating process.

    — Mike Duensing

  • WSO2 Advances Microservices Gateway

    WSO2 Advances Microservices Gateway

    At the Open Source and Software Development Conference (OSCON), WSO2 this week announced it has updated an open source microservices gateway to make it possible to expose multiple microservices through a single application programming interface (API).

    Additionally, version 3.0 of the WSO2 API Microgateway now includes the ability to automatically discover microservices and transform legacy API requests into a more modern format. WSO2 also added support for the OpenAPI Specification (OAS), formerly known as Swagger, to make it easier for developers to collaborate on creating APIs, and has separated the WSO2 API Microgateway toolkit from the runtime to enable greater scalability and smoother upgrades.

    Ken Oestreich, vice president of product marketing for WSO2, said the WSO2 API Microgateway is designed to accelerate the convergence of application development and integration into a single team. As part of that effort, WSO2 has been advocating the adoption of Ballerina, a general-purpose programming language designed from the ground up to make it easier for developers to integrate distributed applications on their own. For example, Ballerina makes it possible for developers to create and embed their own micro-enterprise service bus (ESB) within a distributed application, he said.

    Those integration engines then could be deployed and updated within any DevOps processes layered on top of a continuous integration/continuous deployment (CI/CD), Oestreich added.

    A WSO2 API Microgateway is designed to boot up in less than a second and provides authentication, authorization, rate limiting, service composition, discovery, transformation and analytics capabilities. It is designed to be integrated with the WSO2 API Manager, an open source API management platform that can run on-premises or in the cloud.

    As the number of microservices being created within organizations increases thanks to the rise of containers, Oestreich noted there is now a critical need for organizations to find a lightweight approach to building and managing all the APIs required to connect thousands of microservices. WSO2 provides a flow diagram through which organizations can visually manage that process, said Oestreich. As part of its support for containers, the WS02 API Gateway provides built-in support for container orchestration tools such as Kubernetes, which makes it possible to generate artifacts that can be applied directly to Kubernetes clusters.

    Organizations of all sizes are clearly struggling these days with API management. In theory, APIs should remain stable as the software components they connect to are updated. The trouble is, each new microservice generates its own set of APIs, and before too long, organizations find themselves trying to manage thousands of APIs that are all dependent on each other. The removal of any one API might not crash an application, but it could adversely impact performance as API calls are re-routed around the application.

    It’s not all clear these days who inside most organizations is responsible for managing APIs. Developers certainly create the APIs. However, once they are deployed in a production environment, their care and feeding often pass over to an IT operations team. Regardless of whom, however, once any of those APIs break it’s not long before the entire DevOps team knows about it. The challenge now is figuring out how to make the management of all those APIs as natural an extension of a DevOps process as possible.

    — Mike Vizard