devopsy.kinsta.cloud

Tag: application development

  • Wavefront Provides Map for Microservices

    Wavefront Provides Map for Microservices

    VMware announced it is adding a service mapping capability to the Wavefront 3D Observability platform it provides with the Wavefront by VMware monitoring tools.

    Stela Udovicic, senior director of product marketing for Wavefront, said Wavefront Service Maps will make it easier for IT organizations to visualize what will soon be thousands of microservices running highly distributed computing environments, including those based on containers running on Docker Engine, connected via service meshes such as Istio or spanning proxy servers such as Envoy.

    Capabilities provided by Wavefront Service Maps include packaged visualization of request flows with a map of service dependencies, built-in tracking of health metrics and view into individual traces to pinpoint performance bottlenecks.

    Accessed as a set of software-as-a-service (Saas) applications, Wavefront by VMware relies on an agentless approach to monitoring that supports all the major public clouds along with providing integrations with platforms such as Kubernetes, GitHub, Slack, PagerDuty, Kafka and Pivotal Application Service.

    Udovicic said by making it easier to visually identify and troubleshoot microservices, IT organizations should be able to accelerate their transition to modern cloud-native applications. Building and deploying a single application based on microservices is complicated enough. Trying to support hundreds of those applications is simply too daunting without the ability to visualize all the interdependencies between those services. Troubleshooting any issue then becomes easier because Wavefront Service Maps is designed to enable DevOps teams to drill down to the traces being employed to monitor the application, she said.

    Earlier this year, Wavefront added support for distributed tracing and machine learning algorithms that also make it easier to identify anomalies within a microservices-based application.

    In terms of adoption of cloud-native applications, Udovicic said there are basically two classes. The first are early adopters who are already highly committed to developing cloud-native applications. The bulk of the enterprise IT community, however, is still in the early stages of building and deploying these types of applications, said Udovicic.

    There’s naturally a high correlation between organizations that have adopted cloud-native application development using microservices aggressively and those that have implemented best DevOps practices. In fact, one of the benefits of a visualization tool is that it makes it easier to bring new members on to those teams. Rather than having to piece together what is occurring in the environment, a new member of a DevOps team can visually inspect each microservice they might be responsible for managing.

    It may be a while before DevOps processes become the dominant default method for managing IT. But as DevOps tools become easier to use, the number of DevOps practitioners should increase steadily. Arguably, one of the reasons DevOps adoption is not as far along as it might be is that the learning curve is still too steep. But as visualization capabilities gets added to the analytics frameworks baked into those tools, it’s now only a matter of time before the number of IT professionals that might be intimidated by DevOps processes starts to decline steadily.

    — Mike Vizard

  • Tax Day IT Lessons, or How to Avoid Wiping Out on Your Biggest Day of the Year

    Tax Day IT Lessons, or How to Avoid Wiping Out on Your Biggest Day of the Year

    This time last year, as the Internal Revenue Service (IRS) geared up for its biggest day of the year, a firmware bug deep in its storage network was waiting to take down the system. When Tax Day arrived, the onslaught of last-minute filers triggered a systemwide outage that lasted 11 hours and forced the IRS to extend its filing deadline by a day.

    The IRS has another chance to get it right next week, but its IT team is far from alone in having dropped the ball on its most important day of the year. In 2015, the government’s Healthcare.gov website was plagued by crashes on the day Obamacare launched. Last year, Amazon’s website crashed just as Prime Day kicked off, and a few months later, Walmart’s systems fumbled at the start of Black Friday.

    These glitches can cost organizations millions, not to mention the hit to their reputations and inconvenience to customers. As Tax Day approaches, it’s worth looking at some steps any organization can take to avoid embarrassing or costly glitches when a big day arrives. These occasions are fraught with risk due to sudden traffic spikes or untested code.

    Here are steps organizations can take to minimize the chance of disruption.

    Have a Deployment Process You Trust

    People often talk about a code freeze as a solution, but this shouldn’t be your first instinct. A code freeze ties your hands from making last minute changes, and let’s face it, few teams have their code buttoned down months ahead of time. Far better is to have a rock-solid deployment process that gives you confidence that what you’re shipping won’t break. Here are some elements it should include:

    • Trusted testing gate before production. You and your team need confidence that you’re shipping code that works on the devices and browsers your customers use. There are many ways to do this but focus on these elements: speed of throughput needed, the level of risk you are willing to tolerate and the cost to your business of bugs making it to production.
    • A totally automated process with no human bottlenecks. There’s nothing like trying to ship a fix to production, only to realize the engineer with permission to approve the release is on PTO.
    • Proper environment escalation. Contrary to the above, never ship direct to production! Have a proper staging server that is a good enough replica of production, so you can test your application in conditions that match production.
    • Good test data management. This is one of the areas where software companies fall down. Stale data, data that doesn’t have edges or nuances like in production and data that contains personally identifiable information (PII) are all very common culprits—this is one of the most difficult things to get right with testing.

    Stress Test for Robustness

    In high-traffic periods, new stuff breaks. Stress testing helps to ensure services will continue running under a heavy load, but you need a realistic approach grounded in actual user behavior. Can you handle 20,000 users, all trying to register at once when your new app goes live? What pathways will customers take through your website or application? What features have caused problems in the past? Identify common pathways and potential problem areas and stress-test the hell out of them.

    Build a Culture of Quality

    One reason big events are scary for engineers is the sudden emphasis on accountability and quality that was lacking before. Solving for quality at the eleventh hour is guaranteed to be less effective and efficient than building a culture of quality from the start. Much like most management, the only way to do this well is to create accountability for your teams and give ownership of quality directly to them. A few quick ideas: Add a functionality review to your code review step, provide tooling to your team so they can drive testing themselves on pre-production features and make them feel the pain of bugs getting into production by having an engineering support rotation.

    Measurement and Metrics

    Achieving this culture of quality depends partly on good measurement and metrics. Sadly, this is one of the weakest and least-defined areas of development today. Since it’s impossible to directly observe quality in production—since you can only know about the bugs that are caught—it’s more productive to create some measure for QA process coverage and tie that off to the business. One way to do this is to look at the differences between how your customers are using your application in production, versus how you are testing it pre-production. This can give you a lot of insight into the areas that are under-covered or over-covered and can be a useful way to measure whether incremental investments in QA will actually be ROI-positive.

    If You Can’t Do Any of That … Fine, Resort to a Code Freeze

    If you don’t have a bulletproof deployment process, a code freeze is a brute-force option. It ties your hands from making last-minute changes, but at least ensures you won’t add new risks without adequate time to discover them. The duration depends on how long it takes your team to surface production issues, based on past experience. If you don’t have that data, six to eight weeks may be a safe period. But really, if this is your main strategy for avoiding problems on game day, you’re probably in the wrong job.

    Review Patch Management Policies

    This one might have helped the IRS. Its storage vendor, IBM, had issued a patch for the bug that brought down the system months earlier, but the IRS didn’t apply it because it was part of a code bundle that didn’t meet its production testing requirements. A government report concluded that the IRS needs to vet those decisions more effectively and document the process. Bottom line: Have a structure and process in place that ensures you’re making informed, sensible decisions about whether to apply new patches.

    Other issues contributed to the IRS meltdown: Its storage system had no automatic fail-over or built-in redundancies, creating a single point of failure. It was unfortunate that several factors conspired against it, but luck isn’t something you should depend on. Executing successfully for a big event isn’t achieved in a few short months beforehand. It involves building the right culture and practices to guide your development and operations year-round. This will greatly minimize risk and the work you need to do to be prepared.

    — Fred Stevens-Smith

  • TypeFox Ties Cloud-Based IDE to GitHub

    TypeFox Ties Cloud-Based IDE to GitHub

    TypeFox has launched a GitPod.io service that melds the integrated development environment (IDE) based in the cloud from TypeFox with the open source GitHub repository.

    Sven Efftinge, co-founder of TypeFox, said this level of integration will make it easier for developers to navigate multiple projects from which they pull code from GitHub into an Eclipse-based IDE.

    In addition, when developers open a Gitpod.io workspace, they will find that any build involving an update to an artifact housed in GitHub will have been automatically completed, said Efftinge. That will reduce substantially the amount of time developers spend waiting for build to finish, he noted.

    TypeFox collaborated with Google, Ericsson, Arm and Red Hat to develop the open source Eclipse Theia project, which provides a foundation for building IDEs in the cloud using TypeScript, CSS and HTML for a desktop-like user experience. At the highest level, Theia consists of a front end running in a browser or in the local desktop application and a back end running on any host or locally within the desktop application. Both the front end and back end communicate through JSON RPC over WebSockets. TypeFox then leveraged that project to build its own cloud-based IDE.

    Gitpod.io further advances the collaboration capabilities that are inherent of cloud-based IDE by adding the ability to capture and share snapshots of the development environment.

    Efftinge said following initial support for GitLab, the next effort will be focused on integrating Gitpod.io with the GitLab repository, which is used widely in traditional enterprise IT organizations.

    Regardless of the repository employed, more attention needs to be paid to reducing the daily friction developers encounter when developing applications. While best DevOps practices go a long way to accelerating application development and deployment, there a lot of wasted steps during the development process that, if eliminated, would increase developer productivity substantially. Of course, the more productive developers become, the more applications there are moving through the continuous integration/continuous development (CI/CD) pipeline.

    It’s still a bit unclear to what degree application development will move to the cloud. It’s certainly easier to streamline development process in the cloud. But many developers remain attached to individual workstations because they may not always be in a location that has reliable access to the internet. However, as application development—especially in the age of microservices—becomes more of a team sport, it’s clear that more application development is being pushed into the cloud. Pushing application development into the cloud also provides the benefit of reducing the number of high-end PCs and workstations an organization may need to acquire for its developers.

    Whatever the path chosen, it’s clear repositories such as GitHub and GitLab are now at the center of application development. Very few developers these days are writing raw code. Most of them are combining artifacts stored in repository to build their applications. The challenge organizations now face is bringing some consistency to what otherwise could easily become a chaotic process.

    — Mike Vizard

  • Using Product Experimentation for Continuous Improvement

    Using Product Experimentation for Continuous Improvement

    Organizations are embracing product experimentation as a tool for continuous improvement

    Companies that embrace product experimentation are able to capture highly accurate data about markets and product ideas and gain intelligence about market trends. As a result, these companies are able to continuously deliver innovation and measure business outcomes.

    Industry leaders such as Netflix, Instagram and Facebook have used product experimentation to maximize a positive customer experience, increase their user base and elevate their market positions to the highest of levels.

    Let’s say you want to be one of those companies—or at least you and, hopefully, your team, want to experiment with product features in hopes that your company will embrace experimentation on a larger scale to achieve continuous improvement.

    Great. But now what?

    Just thinking about learning the basic concepts of experimentation and figuring out where to start can seem like an overwhelmingly daunting task. Fortunately, there are a few tried and true steps you can take to get on the path to product experimentation for continuous improvement.

    Measure First

    “You have to walk before you can run.” That old adage certainly applies here. Rather than attempting to jump headfirst into experimentation, organizations first must ensure they are measuring things. Are you tracking things such as users per day, trends, dates and conversions? The idea here is to become data driven, because before an organization can run effective experiments, it first must gather quantifiable data; understand what this data means for overall growth, user retention and long-term projection; and then base business decisions on this data.

    Buy or Build 

    No matter the size and scope of the experimentation throughout the organization, even if it is just one team or department, you need a platform or tool to experiment on. Many of the most progressive organizations that have based their growth and continuous improvement on experimentation have built in-house solutions to facilitate this. However, this can be time-consuming from the start and the platform will continue to require attention as it evolves. This evolution also requires a specific skill set to make it happen—specifically, data science and engineering—to ensure the experimentation platform is statistically sound.

    For most, investing in a robust tool or platform built specifically for experimentation is the best option. Most experimentation platforms allow you to plug and play, which provides the right features and capabilities to get an experimentation started quickly.

    Hypothesize

    The next step is to create a testable hypothesis and then record and analyze the data during testing. It’s important to begin thinking in terms of hypotheses, as framing plans and ideas in this manner makes them easier to reuse. In other words, being able to say, “Based on this, we predict we can move that metric,” makes your processes very repeatable. Getting into this mindset and having a standardized format—in terms of how things are designed and reported on—makes the lives of everyone on your team easier, as they can simply replicate similar experiment designs. And they will have fewer excuses not to.

    Keep It Simple

    Now that you have quantifiable data and some hypotheses to work with, you are ready to dip a toe into the experimentation pool. It is always a good idea to start with a single simple experiment first, no matter how small. For example, experimenting on a known pain point in your product is a nice place to start. Once you can successfully run an experiment that allows you to fix something in your product that you know is a problem, then you are ready to move on to bigger things such as revenue creation.

    Choose the Right Metrics

    As your team’s product experimentation efforts become more sophisticated, choosing the right metrics—and more importantly, your overall evaluation criteria (OEC)—should become a top priority in continuous improvement. Your OEC comprises the most important metrics of your experiment and it’s a measure of long-term business value or user satisfaction.

    In choosing which metrics to use, there are three essential characteristics of an effective OEC to consider.

    The first of these is sensitivity. This means the metrics you have chosen should be adjustable due to small changes in business value or user satisfaction, which helps ensure the result of an experiment is clear within a reasonable time period. For example, let’s say a customer only buys something from your website once or twice year. That’s not a very useful metric for an experiment since it would be difficult to influence.

    Next is directionality. Your metrics should be moving in one direction or another based on whether your overall business value increases or decreases. That said, the direction some metrics take can be ambiguous. For instance, say you are attempting to measure customers’ engagement with your support team. An increase in that metric could be a positive thing because it might be an indication that more people are engaging with your core product. On the other hand, a decrease in this metric could be an indication that your core product has become easier to use and therefore now requires less support.

    The third characteristic to consider is understandability, meaning the metric should be easily understood, both in terms of its direction and its definition, by your entire organization. Moreover, you should ensure it ties the experiment directly to business value.

    Of course, much more will need to be done to transform your organization into a place that truly embraces an experimentation culture and reaps the benefits that it brings in terms of customer experience and beyond. But these steps should set you and your team down the right path.

    — Sophie Harpur

  • Pivotal Software Previews Automation Framework

    Pivotal Software Previews Automation Framework

    At the North America Cloud Foundry Summit 2019 conference, Pivotal Software announced it is beta testing an automation framework that promises to keep its distribution of the platform-as-a-service (PaaS) environment continuously updated.

    In addition, Pivotal revealed it will be adding support for open source technologies including Envoy load balancing and Istio service mesh software developed outside the auspices of the Cloud Foundry Foundation (CFF) to its Pivotal Cloud Foundry (PCF) distribution. Envoy and Istio are being employed to add a new routing tier to tier to PCF to give developers more control over network traffic.

    Richard Seroter, vice president of product for Pivotal, said Platform Automation for PCF consists of a series of building block modules that will be applied to all the components of PCF as well as eventually the distribution of Kubernetes that Pivotal curates in collaboration with sister company VMware.

    Pivotal also announced that Pivotal Application Service (PAS), the runtime for PCF, will soon support Windows Server 2019 along with the ability to configure multiple custom ports per PAS container to make deploying containerized applications in a PaaS environment more efficient from a networking perspective.

    Finally, Pivotal is adding more descriptive metadata to the application programming interfaces (API) it exposes across the PAS runtime.

    Seroter said Pivotal continues to focus on automating as much of the IT operations pipeline as possible. Rather than allocating IT staff to create and manage these pipelines, Pivotal is making a case for relying on a set of managed services that span instances of Cloud Foundry and Kubernetes running on top of virtual machines deployed on either a public cloud or on-premises. That approach relies on a highly opinionated operational pipeline defined by Pivotal that IT organizations will need to adopt to benefit from a highly consistent and repeatable approach to managing IT operations at scale, he said.

    The need for a more structured approach to managing IT operations is only becoming more acute as organizations embrace Kubernetes platforms alongside Kubernetes, Seroter added. In fact, a survey of 501 IT leaders published by the CFF finds almost half of respondents (48%) report using some combination of PaaS, containers and serverless technologies together.

    It’s still unclear how much IT organizations will standardize on a particular application development platform. PaaS environments typically have a more robust set of application development tools, but they can consume tens of virtual machines to stand up. Development tools for Kubernetes platforms are still evolving, but the platform provides a more efficient way to consume both virtual machines and bare-metal servers. It is apparent that for some time to come that many IT organizations will find themselves managing multiple platforms. The challenge that creates for DevOps teams is finding a way to manage those platforms consistently using a common framework rather than having to deploy and master separate management. It may take quite a while for IT leaders to rationalize their management platforms, but with each passing day it becomes clearer that goal increasingly is within reach.

    — Mike Vizard

  • IoT Future-Proofing for the Long Haul

    IoT Future-Proofing for the Long Haul

    Think about this: The IoT application your DevOps team is developing right now, if successful at scale, will likely be the longest-living application in your shop. It may even outlive the tenure of many of your team members with your company. Is IoT future-proofing possible over a life cycle of 10 years or more? Yes, with some insight for the long haul borrowed from industrial and defense computing experience.

    That may sound counterintuitive for DevOps because those industries aren’t exactly known for agile processes. They’re designed around minimizing change and containing risk in mission-critical situations. IoT technology is evolving rapidly and it’s difficult to say what things may look like in a year or two, much less 10. What IoT applications have in common with industrial and defense systems is that they are often complex. Your operational technology (OT) people probably appreciate how complex their existing production environments have been. IoT applications add elements of wireless connectivity, cloud architecture, real-time performance, end-to-end security and algorithmic sophistication.

    At-scale IoT applications will require mastery of complexity, and lessons learned can help. The objective is not to avoid change but rather to “build the airplane while flying.” The core DevOps concept of continuous application release and testing needs to extend beyond just the application code. Teams will need to be detail oriented, looking at device configurations, interoperability, data integrity and how analytic insights evolve as data accumulates.

    Device Configurations

    Buying an enterprise server usually means selecting a commodity: Pick a processor model and frequency, memory size, number of Ethernet and USB ports, storage interfaces and packaging. In the cloud, selections in elastic instances are even easier. As long as the box fits and runs the desired operating system, the details of what’s inside aren’t that important. If you have to buy another one in two or three years, there are likely higher performance choices available.

    In long-lifecycle computing for IoT applications, boxes aren’t commodities. Real-time performance drives differences in processor and board architecture. If you have to buy another one in two or three years, that could be a problem. Vendors often offer industrial and defense customers revision control services, ranging from notification of changes to extended availability of specific configurations. Assuring supply sometimes means a lifetime purchase of components, perhaps as bonded inventory for a customer.

    Interoperability

    Even simple IoT devices, such as wireless sensors, can present a problem on a 10-year scale. Connectivity specifications evolve, with both major changes and minor revisions. Cellular standards reach sunset as mobile subscribers leave them behind. Vendor support for older gear is often given reluctantly, frequently expensive and sometimes non-existent unless an upgrade is executed.

    Choosing interoperable frameworks with robust ecosystems will be critical for success in the long haul. Teams should be prepared with a “plan B” if a vendor is acquired and stops offering a specific configuration, or if they cease operations altogether. Devices with over-the-air (OTA) programming help keep pace with specification changes and alleviate security concerns as they arise.

    Data Integrity

    Teams won’t be able to just stop the IoT plane and work on it. Data collected on day 1 will be just as valuable as data collected on day 3650, if it’s handled correctly through IoT future-proofing tactics. Often, IoT devices connect to networks easily. The real test of an IoT application comes when data starts flowing, perhaps from thousands of devices. Is the data from an authorized device? Is all the data in the correct format? Is it time-stamped properly? Is it checked for errors and missing frames?

    Presumably, when an IoT application succeeds, the temptation to scale quickly sets in. Suppose a new group of sensors is added with the same class of information in a slightly different format. The system should abstract formats and sanitize data at the edge, so all data reaching the cloud is ready for algorithmic processing. For example, JSON is one tool that can help with abstraction. Edge computing may also use generative models to reduce data transmitted to the cloud, forwarding only out-of-bounds conditions for further analysis.

    Analytic Insights

    At the onset of an IoT project, teams have an idea of what they have set out to accomplish. Inevitably, as projects mature new insights come out of analytics. The architecture may not be optimized to deliver those insights in real-time, and changes may be necessary to speed up delivery of algorithmic results. Workflow optimization is an ongoing process for IoT teams. This is the ultimate instance of rebuilding the plane while in flight, extracting more value from an in-place system.

    The Ethos of IoT Future-Proofing

    IoT future-proofing is possible by embracing both the longevity and the complexity of the application. Shifting your team ethos from maintaining a static configuration to developing a living application architecture, helps overcome events certain to happen over a 10-year life cycle and beyond.

    — Don Dingee

  • SoulCycle Flexes Its Muscles with DevOps and CI/CD

    SoulCycle Flexes Its Muscles with DevOps and CI/CD

    When SoulCycle wanted to improve application development and deployment, including improving services for customers across its 80-plus indoor cycling centers in the United States and Canada, the company turned to Mark Sost, a veteran developer and engineer who worked at several media companies, including Hearst.

    Over the last two-plus years, Sost, who now holds the title of senior director of engineering at SoulCycle, has built-up the company’s engineering and DevOps teams, increasing the headcount from eight or nine developers to about 40 employees now.

    The first major project was revamping a legacy, LAMP-based stack used to support applications to focus more on a modern platform that could take advantage of DevOps methodologies, as well as continuous integration and continuous delivery practices (CI/CD).

    Sost and his team dubbed this new platform Podium. However, Podium is more than a development platform, Sost explained.

    “Podium became the ethos and the methodology, as well as the architecture and application stack for re-platforming Soul’s technology stack in total,” Sost said in a telephone interview. “We moved from that monolithic to more of a service-oriented architecture. As such, we started to break out functionality on multiple applications.”

    The re-engineering also meant investing in new infrastructure, as well as other cloud-based technologies. This includes a multi-cloud approach.

    While most of the legacy applications have now been moved to Amazon Web Services, SoulCycle also uses Google Cloud Platform for Podium and all new developments. Sost also takes advantage of Kubernetes and Docker for container orchestrations, as well as investments in other managed services.

    Other tools in the DevOps arsenal include Jenkins to run unit tests; DataDog and StackDriver for monitoring and analytics for workflows; combing Travis CI, Cloud Builder and GCR for CI; and technology from startup Harness, which provides CD-as-a-service. Sost called Harness the “last-mile” tool needed for application deployment.

    “For Harness, that’s CD for us,” Sost said. “That’s continuous delivery to our various Podium environments. We’re leveraging it for delivery to all our Podium environments. Everywhere from UAC (user account control) during the code review cycle to QA after merge, to production, load test and everywhere in-between.”

    This revamped approach to application development now means that the SoulCycle engineering team has created approximately 30 different apps over the last 24 months, this includes internal apps used within the company environment, and ultimately to customers using the facilities and equipment.

    Additionally, Podium helps create a more unified architecture to help ensure that the entire team—whether it’s DevOps, QA or the production team—can paint a 360-degree view of the problem that needs to be solved and what the implications are for the business once the solution is put into place.

    This is what Sost and his team call “Podium principles.”

    “When we say that we’re building things with Podium principles in mind, we’re talking about the fact that everything is version-controlled,” Sost said. “We have full test coverage. We have everything in terms of Kubernetes manifests to infrastructure automation written down and version control checks it as part of source code. That applications are conforming to more of that 12-factor methodology and that we’re really focused really heavily on developer empowerment.

    “I think for us, that really is a shift that Podium has introduced; a move from writing the code as an application developer and then throwing it over a wall to an operations person—a QA person—to test it and deliver it somewhere,” Sost added. “Instead, we provide a developer the tools and the patterns of principles to go about controlling more of their application development life cycle all the way through to delivery.”

    The results have helped improve the overall SoulCycle experience for customers, which includes:

    • Reducing deployment time by approximately 80 percent.
    • Instead of one hour, deployments now take one developer 10 to 15 minutes.
    • QA verification has been reduced by approximately 80 percent.
    • It now takes three QA engineers one hour to verify, compared to three to six hours previously.

    At the same time, Sost believes that the Podium approach gives developers more control over their projects and lets them focus on writing good code that creates apps people want to use.

    “It’s more, ‘Now, I know what’s involved with getting my application to people,’” Sost said. “Because at the end of the day, engineers are just concerned with writing things that people want to use. … This is how we’re going to give you more control of the code and applications that you’re writing, so that you can see meaningful results quicker, without having to wait for someone.”

    What’s next for Sost and his team at SoulCycle? The answer: Machine learning and a bit of automation to the DevOps process.

    Here, SoulCycle is using Harness tools to log more data and infrastructure monitoring into the platform, which allows the algorithm to learn more about the various development projects. This can make the code better and eliminate errors that come with constant development and deployment.

    “We’re letting it get smarter over time around how it can detect anomalies and understand whether our code was successful because there are going to be times where things slip through unit testing or slip through integration tests and there are even going to be times where they slip through load tests, where things like 99 percent are just not going to cut it,” Sost said.

    — Scott Ferguson

  • DevOps Chat: JFrog Acquires Shippable

    DevOps Chat: JFrog Acquires Shippable

    The big news in DevOps today was the acquisition of Shippable by JFrog. This adds a CI/CD solution to the JFrog Enterprise+ platform and further expands JFrog’s end-to-end DevOps offering beyond Artifactory and more.

    In this DevOps Chat, we speak with Shippable CEO Avi Cavale, JFrog CEO Shlomi Ben Haim and JFrog VP of Marketing Ayally Goldschmidt about the thinking behind this acquisition and JFrog’s plans going forward.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, you’re listening to another DevOps Chat. Today’s DevOps Chat has some breaking news. It was just announced this morning—JFrog has acquired or merged with Shippable in a rather, you know, this is big news within the DevOps world, and we’re very, very happy to be joined by the CEOs of both Shippable and JFrog. From Shippable, we have Avi Cavale, and from JFrog, of course, our friend, Shlomi Ben Haim. And joining us from JFrog is Ayalla Goldschmidt, who really runs marketing at JFrog. I’m not sure of your exact title, Yes, Ayalla?

    Ayalla Goldschmidt: VP of Marketing, thank you, Alan.

    Shimel: VP of Marketing—thank you for joining us. So, first of all, to all three of you, congratulations, Mazel Tov as they say in Seattle. [Laughter]

    Goldschmidt: Thank you, thank you.

    Shlomi Ben Haim: [Laughter] Thank you, Alan.

    Shimel: Thank you. And so, you know, Avi, let’s turn it over to you first. I think a lot of our audience is familiar with JFrog, and most of our audience have heard of Shippable, but let’s just lay that right out there. What’s Shippable about?

    Avi Cavale: Shippable is about a modern CI and CD platform. So, our focus is to streamline the delivery—packaging and delivery of software, and that’s kind of where we are focused on.

    Shimel: Fantastic. So, Shlomi, I think I already know the answer, but I’m gonna ask you—why Shippable for JFrog?

    Ben Haim: That’s a great opening question. Actually, Alan, you know JFrog very well. You know that everything starts with the culture, and when we met Avi and the team, it looked like we’d found the brother Frogs in a different company. So, for us, it was just to make sure that the technology and the strategy are aligned. And when we looked at the technology and the next generation of CI/CD that was built by the Shippable team with Avi’s leadership, it was a no-brainer for us.

    Shimel: Absolutely. But the other thing I think we should mention is, you know, JFrog, many people know JFrog from Artifactory, maybe Xray, you know, point solutions that we can call up. Artifactory is a whole platform in and of itself.

    But, really, the big move for JFrog—and if I’m wrong, correct me; Ayalla, you’re the Marketing person—the big move for JFrog was, you know, this JFrog enterprise platform. And, to me, if you’re gonna have an enterprise platform in the DevOps space, you need that CI/CD pipeline kinda delivery capability.

    So, to me, you know, this really kinda helps fulfill that vision of the JFrog platform. Yeah, no, wrong?

    Goldschmidt: Yeah, that is exactly right, Alan. That’s the vision that we have for it. Obviously, we’ll be doing a lot of work here in the coming weeks to clarify the roadmap and the timeline, but you hit the nail on the head. That’s the value that we’re seeing for our customers and what they’re looking to, what they’re asking us for as far as, you know, we love JFrog, we have very happy customers, they love what we do, and they’re looking to take it to the next level.

    Shimel: Excellent. So, let me ask my next question to Avi and Shlomi, and that is, you know, I guess it’s part of the maturation of the DevOps market where all—you know, there are now, everybody wants to offer the whole enchilada. Do you know what I mean?

    Ben Haim: [Laughter]

    Shimel: People aren’t content any more just offering a piece of it, we wanna offer it all, that whole SDLC, we’re gonna help you throughout that life cycle. It seems everyone is pointing towards that, and the money—look, JFrog, it’s no secret, raised $165 million. Some of your competitors have raised also eight figures. That’s where the smart money’s going, towards companies that are building out this end-to-end DevOps framework.

    Avi, is that what you saw at Shippable, and is that what attracted you guys to want to do this deal with JFrog?

    Cavale: Yeah, I think what we are seeing is that there is one thing which is very critical for customers. It’s like—yes, they want the whole enchilada as a single platform, but at the same point in time, they also want a platform that is open, and they want to make sure that they can plug in the tools that they like in certain places.

    So, of course, they want to see the native capability end to end, but extensibility is also super important. And so, what we kind of saw with what JFrog was doing and what we were doing also was that we were being open to everything. I mean, yes, we want to have a standard of how we think about an end to end platform, but we want to be open and make sure we embrace all the practices that developers want to do and extend the platform to DevOps capabilities.

    Shimel: Absolutely. So, Shlomi, Avi makes a very good point here, and that also goes to the heart of JFrog. One of the things about JFrog is that they play nice with everyone, basically, right? You could pick whatever CI/CD platform you wanna work with or whatever—you know, whether it’s Puppet or Chef or the Red Hat software, you know, JFrog works with everyone, so to speak.

    But now, you have an in-house CI/CD solution, so how do you balance that in your go to market?

    Ben Haim: That’s a great question, Alan. I think that what we’ve started to see in the market for more than 12 months now is that DevOps is maturing and the organization and enterprises are looking to get an end to end solution, yet the driving force of DevOps production is still in the hands of the developers, which, obviously, would love to see the freedom of choice and the best of breed options kind of open to them.

    So, you are right. Our universal approach is something that always led us. We always provided our users with the power of choosing their tools pack, and it will still be the case.

    However, on the JFrog platform, what we call the enterprise class, we want to make sure that we take artifacts seriously, from the moment you build it from code all the way to production. And, together with Shippable automation power, together with the integration and the visibility that technology like Shippable can provide to the platform, I think we will be able to combine the two, to allow a better universal approach. So, you can still use your Jenkins, your CircleCI, your other DevOps tool sets. But you will also have a JFrog end to end solution that takes you all the way from code to production.

    Shimel: Excellent. So, Avi, you know, how do you—I’ll reverse, mirror that question back to you, right? How do you see the Shippable team, the Shippable product fitting into that JFrog Enterprise Plus, you know, the Artifactory platform, all of the different tools that JFrog and services that JFrog is putting together—how do you make sure you fit in there?

    Cavale: So, as Shlomi mentioned, right, what is happening is—so, the artifact is something that is immutable, and that’s something that you build and you want to kind of take it through your entire value chain of how you deliver software to your end customers or end devices or whatever they might be.

    The issue is that, if you don’t have the pipes to kind of control that in a high fidelity fashion, you lose a lot of information as you go from stage to stage. Because you’re leaving it up to the customer to make sure all the data is being persisted and you’re keeping all the hooks so that eventually what you’re really trying to do is, you want to be able to go to something that’s running on the end device and be able to track, if there are problems, what are all the pieces that went into actually building that piece of software that is running there?

    So, losing that ability to connect that entire life cycle, all the way from code to the point where it’s running on a device is a very critical piece of DevOps. And what we see is, that kind of, now, our marriage to the whole Artifactory plus Xray and plus distribution, all of those pieces now can be connected through a common pipeline and we’re making sure that we have high fidelity information exchange as things move through this work flow end to end. And I think that’s kind of the critical thing that we are adding to the product.

    Shimel: Excellent. Ayalla, a question for you—you look at, all of a sudden, you’re embarrassed by the riches of JFrog in terms of their product, right, in terms of the product that you have to work with, the products that you can bring to market. But at the same time, at some level, it’s a double-edged sword from a marketing perspective, right? You have so much now, too, that you need to market, that you need—how do you make sort of a holistic message for market that includes all of these pieces and how they fit together and how, if you don’t want to use all the pieces, you don’t have to, either?

    Goldschmidt: You know what, I feel like the luckiest marketing person on the planet. And, you know, Shlomi promised me when I joined this company a little over a year ago that there will be no shortage of news, and he has delivered.

    Shimel: [Laughter]

    Goldschmidt: So, since I’ve joined, the acquisitions, our Series D announcement, and of course, all of the new technologies that we’ve supported along the way, and the most recent exciting edition of support for Go and Go Center, we love all of these audiences and we do actually put in a big effort in tailoring our message to make sure that we’re communicating with a developer first mindset, and that seems to be working for us.

    So, you know, until today at JFrog, everything we’ve built has been through an inbound marketing funnel with an inside sales team. We haven’t had field people knocking on doors, and that seems to be working great for us, and now we’re ready to take it to the next level. But we’ll always remain developer first.

    Shimel: Excellent. Let me—Avi, let me ask you some sort of typical M&A kind of questions. So, is your whole team staying on as part of this acquisition?

    Cavale: Absolutely, and we’re all joining the JFrog family, and so there is really no change to the business and how we are running it. And I usually tell my team that I have a new boss, that’s all—nothing else is changing, and we’re gonna keep marching towards the vision, and all we have is an opportunity to broaden that vision that JFrog brings to the table and we are part of a much bigger family than what we were before.

    Shimel: Excellent. And so, Avi, what do you see particularly as your role going forward, here?

    Cavale: Sorry, was that for me?

    Shimel: Yes, specifically you—what’s your role going forward? Is it just heading up Shippable? I mean, I’ve been in your role, to tell you the truth. I’ve had my company acquired more than once. And, while you still want to maintain your team and run the team, you also need to integrate now, right? You’re part of an executive team at JFrog that has—I will tell you, I think one of the best cultures in the DevOps world or in the tech world, period.

    You know, how do you see yourself? How do you see this changing your role? It’s more than just having a new boss.

    Cavale: I think the way—I’m actually in Israel right now, and we have already started collaborating. So, one of the things that I actually see is that the team is like, it’s all about brainstorming, quick integration. So, my role is to make sure that I’m delivering the products that JFrog’s customers love as well as most importantly the trust that it actually runs the way it needs to be running. And we’ve focused on the CI/CD aspect of it; nothing is changing from that perspective.

    But what I have now is more brains who are kind of helping me think through what we need to actually do so that we are focused on the enterprise and driving towards that, so that’s kind of how I see myself, as part of the team.

    Shimel: Excellent. So, Shlomi, let me ask you, now—what’s next? What worlds are left to conquer? What pieces of the puzzle are missing? What’s next?

    Ben Haim: You know, Alan, I’m sitting here and listening to Ayalla and Avi and this is great. And from people from outside JFrog, they might think that JFrog is trying to complete the pipeline with all kinds of pieces.

    But the one great feedback that I’m getting from the community is that there is no question mark. People understand what are we doing, it all makes sense. Every tier, every brick that we put on the DevOps wall sounds like the right, next logical step.

    But we are the binaries people, and we will stay the binaries people. We will just make sure that this pipe is completed, and when we speak about the liquid software vision, when we speak about continuous update and solving the pain for the DevOps world, we are taking it seriously, and, as you see, we are super determined to complete our mission.

    What next? We have to stay focused, we have to be a great solution to our customers and users as a community. We are very active in the community, providing them with more tools and more capabilities. It is now our responsibility to make sure that Shippable is fully integrated and the user experience is smooth and fun to use, and as Ayalla mentioned, thinking of the developer first and not the full platform story, but the user experience and the fun and simple-to-use solution.

    Shimel: Excellent, excellent. Alright. Guys, we’re about out of time, I think. We’re probably over time. But again, Avi, congratulations. Welcome to the JFrog family.

    Cavale: Thank you.

    Shimel: It’s an amazing culture, and I’m sure you probably already know that, but you’ll continue to find out. Shlomi, my friend, congratulations to you. Keep up the great work. I can’t wait to see you.

    Ben Haim: Alan, thank you.

    Shimel: Thank you.

    Ben Haim: Thank you so much, partner. Thank you so much.

    Shimel: Alright. And Ayalla, always a pleasure.

    Goldschmidt: [Cross talk]

    Shimel: You, my friend, have work ahead of you now. [Laughter]

    Goldschmidt: [Laughter] Yes, I do. The work is just beginning.

    Shimel: Good for you.

    Goldschmidt: Thanks for having us on.

    Shimel: Alright. So, big news today—JFrog acquires Shippable, and another brick in the wall, as Shlomi mentioned. I tend to think of it as more of a Pink Floyd song than any political thing, but it certainly is continuing this DevOps maturation.

    Guys, congratulations. We’ll see you all soon. And for now, that’s a wrap on this DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. Have a great day, everyone.

    — Alan Shimel

  • Deploying into Azure App Service using Azure DevOps CI/CD Pipeline

    Deploying into Azure App Service using Azure DevOps CI/CD Pipeline

    This article demonstrates how to deploy an application into Azure App Service using Azure DevOps (VSTS) continuous integration/continuous delivery (CI/CD) pipeline.

    In this article, you’ll create a sample environment to:

    • New build based on code commit to your Azure DevOps Repo.
    • Automatically deploy your app into Azure.

    Prerequisites:

    • Azure Portal Account, Azure subscription and Azure DevOps (VSTS) account.
    • Azure Resource Group.
    • Create a web app in Azure. Make note of the app service URL—you need it later.

    What is Azure App Service?

    Azure App Service enables you to build and host web apps, mobile backends and RESTful APIs in the programming language of your choice without managing infrastructure. It offers auto-scaling and high availability, supports both Windows and Linux, and enables automated deployments from GitHub, Azure DevOps or any Git repo.

    Creating Resource Group in Azure

    Once you have a subscription in Azure, you need to create a resource group to manage resources in Azure. The best practice is to maintain a separate resource group for each environment (DEV, INT, QA, STAG, PERF, PROD) and follow the proper naming conventions. To create a resource group, select Resource Group from left-side blade, click on +Add, then select Subscription, give a proper name to the resource group and click on Review + Create.

    Creating App Service

    Click on All resources from the left-side blade of the panel and click on Add, then select Web App and give a proper name to your app service. Then select Subscription and select the existing resource group. Keep the remaining option as default. and click on Create.

    Once you have created the app service, click on that app service and go to Overview. There you can identify all the details that belong to this app service, including status, resource group, subscription and URL (please make a note of this; you’ll need it later).

    Creating Service Principal

    When an application needs access to deploy or configure resources through ARM or VSTS in Azure, you’ll need to create a service principal, which is a credential for your application.

    Go to Azure Active Directory -> App registrations -> New application registration, then give a name to the service principle, select application type and give it a URL of your choice. After creating the app registration, go to Settings from that service and make note of application ID,  then go to Keys create a key and copy the secret value. (Note: It doesn’t appear later, so please store it in safe place.)

     

    Create a New Project in VSTS

    The first step is to create an account in Azure DevOps (VSTS), then follow the steps below to start an application deployment. Here I’m taking sample open source java-based code from GitHub repository and importing it to Azure DevOps repo. (You can push your own source code into repo.) It is a simple multi-module Maven project. The application is a very simple online version of Conway’s “Game of Life.”

    To create a new project, click on Create new project, give a proper name to your project and select create. Then go to Repos, click on Import, then select source type, type in the above URL in the Clone URL tab and select Import. The source code will import into your repository.

    We need give service connections to our project, so go to project settings from the bottom of blade in our project home directory and then select Service Connections -> New Service connection -> Azure Resource Manager. Click on “Use the full version of the service connection dialog” from the pop-up, then paste the Application ID into the Service principal client ID tab and the secret key value into the Service principal key tab (which you saved during app registration creation). Then click OK.

    Creating a Continuous Integration (CI) Build

    Go to Pipelines -> Build -> New Build Pipeline, then click on “Use the visual designer.” It will ask source code repo details, so select Azure Repos Git and select Team project, which you created at the start of the project, select Repository and branch name, then click Continue.

    Next, select a template Maven, type in the pipeline name and select Hosted VS2017 for the Agent pool, and click on pom.xml in the Maven POM file. There you can list the goal(s) as Clean Package and select Copy Files. At the contents section please enter **/*.war then go to Publish Artifact: drop, list the artifact name as Gameoflife and keep all remaining options as default values. Then, under Triggers, select Enable continuous integration and give branch filters listed at right, which enables the continuous integration feature. Once a developer commits their changes into master, the CI build will trigger automatically.

    Once the configuration is complete, click on Save and Queue from top of pipeline to trigger a CI build. (Every commit into master will trigger a new build.)

    Creating Continuous Delivery (CD) Pipeline

     Go to Pipelines -> Releases -> New Release Pipeline, then select the template Azure App Service deployment, list the stage name as DEV and click on Add an artifact. Select project and source (build pipeline), then select default version as Latest, click on Add. Cick on Task (below the DEV), select Run on agent and select agent pool as Hosted VS2017, then click on the plus(+) symbol, search for template File Rename and select the .war file from source file and give it the new name ROOT.war.

    In the Display name box, list Azure App Service Deploy. In the Azure subscription field, you need to select a service principal name to authorize the resources. Then choose the App type and App Service name. In the Package or folder selection, select war file and rename it ROOT.war, because for java-based applications we need to deploy our app into a proper directory structure.

    Finally, select the template Azure App service manager and select the Restart option, making sure to select the same subscription and app service name you selected in the Azure app service deploy window. Click on Save, then click on Release -> Create a release -> select artifact build number -> create. Build will then trigger and deploy into the app service.

    Now, your code is successfully deployed into Azure App Service.

    You can access using app service URL from any browser (e.g.,  https://xyz-abc-webjob-01.azurewebsites.net) and you can check whether code is deployed successfully or not using below URL: https://xyz-abc-webjob-01.scm.azurewebsites.net.

    — Srinivas Kudipudi

  • In AI Initiatives and Hybrid Clouds We Trust

    In AI Initiatives and Hybrid Clouds We Trust

    The 2019 State of the Union Address, delivered Feb. 5, was light on anything tech-related. But just a week later, Feb. 11, technology was the focus of an executive order that launched The American Artificial Intelligence (AI) Initiative. Why do we need a national AI initiative, and what does it have to do with DevOps? (Hint: You may need hardware and a hybrid cloud strategy for your AI initiative.)

    Investments in AI technology are exploding worldwide. Most analysts believe that while the total number of startups and equity deals to date still favors the United States, China is spawning startups rapidly, thanks to their recent AI initiative. According to just-released data from CB Insights:

    “While China accounted for only 10% of global AI deals in 2017, Chinese AI startups took 48% of all AI funding dollars that year, surpassing the US in AI funding for the first time.”

    The long tail doesn’t lie. A big global competition here is a good thing, though, and the scoreboard has spurred movement. The American AI Initiative lays out five principles, paraphrased in brief:

    1. We need to drive technological breakthroughs in AI.
    2. We need technical standards for development and testing.
    3. We need workforce training in skills and applications.
    4. We need to be able to trust AI solutions for privacy.
    5. We need both open markets and protection for “critical” technologies.

    Go, Team America! What, you expected more than motherhood and apple pie out of the White House? I’m not going there. I don’t think any administration could prepare the level of technical insight needed for something of this magnitude. It can, however, lay a course and task agencies for technology plans and funding proposals—and about two-thirds of this executive order is devoted to timelines for those.

    Let’s assume this AI initiative comes together with real dollars, and everyone including your competition is at work on AI. You may be thinking, “This is easy. I’m looking at a prominent cloud vendor’s machine learning webpage right now and it says, ‘No machine learning skills required.’ Its solution is based on its libraries of algorithms plus cloud-based workload acceleration hardware.”

    If that approach solves your specific problem, that’s great. Many use cases will fit those offerings. However, I’m thinking that a lot of you out there won’t turn over your data and your privacy control to a single vendor. Based on what I’ve seen, while the public cloud may be fast enough for some use cases, it’s woefully non-deterministic for others. You may be able to afford all kinds of time and elastic cloud resources for training, where time may be measured in weeks or months on bigger machine learning data sets.

    Real-time inference is a different game. There. Will. Be. Slowness. One missed result can be very costly—ask any autonomous vehicle developer, then look at all the hardware sitting in the trunk. Public cloud solutions are woefully non-deterministic, especially as everyone and their dog starts using them. The CEO of another big cloud vendor just said in an event keynote that most AI solutions will split 40/60 private/public cloud. She went on to say if you’re regulated, it’ll be more like 60/40.

    Most current startup investment is headed for AI chips. Machine learning is the ultimate workload optimization problem. By adding compute nodes with clusters of GPUs, FPGAs or dedicated system-on-chip (SoC) designs, inference speed-up is achievable. Whatever approach you chose, you’re probably going to want workload optimization safely in your private cloud instance within a hybrid cloud AI solution.

    You’re also going to want control over differentiation of your solution. Open source AI software solutions are great because they handle a fundamental base of value. However, AI-enabled applications are very likely to run into problems at scale. Open source will get you to prototyping quickly. Your innovation will be tested as real-world, real-time issues develop. If you can get a truly differentiated hybrid cloud AI solution that proves to be fast, reliable and secure, you’ll have a huge competitive advantage.

    Again, this looks like a perfect job for a DevOps team. Here’s where to start on your AI initiative, in increasing order of difficulty:

    • Have someone get familiar with machine learning and AI public cloud solution offerings—those vendors are easily found.
    • Also get familiar with open source frameworks such as TensorFlow, Caffe, Cognitive Toolkit, PyTorch, MXnet, DeepLearning4J and others.
    • Look at your preferred distributed computing framework for recent innovations in AI workload optimization; for instance, a lot of work is happening around Hadoop and Spark.
    • Inventory the problems you think AI might solve in your organization and see how they line up with those potential solutions.
    • Experiment and discover where the bottleneck in your preferred algorithms might be; those will be candidates for a hybrid cloud workflow optimized solution.
    • If there’s a profound bottleneck, you’ll need to evaluate the best hardware solution, meaning someone on your team (or a consultant) should understand GPU code or FPGA design.
    • For the most severe AI challenges, more companies will be considering either off-the-shelf AI chips or custom SoC designs—even companies that have never designed chips.

    My point here wasn’t to provide a primer on AI technology; that’s a huge topic. The American AI Initiative is a call that teams need to move on AI now or risk being left behind in the competitive prop wash. You also shouldn’t wait for someone to generate the exact solution you need out in the marketplace. With the feds driving a sea change in AI, investments and technology will be shifting even more rapidly, and it’s best to get in front of it.

    For the curious, here’s the entire executive order on the American AI Initiative.

    If you’ve started already, how’s your AI initiative going? Are there other areas in AI or machine learning you’re curious about that would be a good topic for future posts? Reach out if you’d like to discuss this.

    — Don Dingee