devopsy.kinsta.cloud

Category: Enterprise DevOps

  • HybridOps: Driving Better Collaboration and Productivity in IT

    HybridOps: Driving Better Collaboration and Productivity in IT

    Over the past 10 years, enterprise technology has experienced an enormous amount of upheaval. Developers started self-servicing, leading to “shadow IT.” The DevOps movement and alignment with Agile methods started gaining popularity, and thought leaders started making statements about how DevOps is the future and ITIL/ITSM and other traditional practices are the past.

    With all these changes, it’s no wonder that the words “digital transformation” have become highly charged and central IT teams feel—not entirely without justification—that their budgets and influence are on the wane. As a result (and partly due to misplaced self-preservation and wanting to stay relevant), these IT teams push back against any kind of cooperation with more developer-centric teams, leading to low levels of digital sophistication and decreased productivity.

    Introducing HybridOps

    This is where HybridOps comes in. We at PagerDuty coined the term HybridOps following feedback from customers to describe the reality of digital transformation in large enterprises—which is one in which technology teams will have a variety of operating models, velocities, tools and practices.

    Rather than a dogmatic focus on velocity and stack-ranking teams according to how “mature” they are, HybridOps focuses on three principles:

    1. Learning culture: It doesn’t matter what operating model (DevOps, ITIL or something in between) teams are using, as long as they can meet the needs of the business and have a culture of continuous learning and improvement.
    2. Communication and empathy: Open communication, constant sharing of operational data between teams and empathy for colleagues are much bigger drivers of digital operations productivity than rigorous adherence to a methodology handed down from executive management.
    3. Autonomy: Teams should have the autonomy to choose and use the tools they prefer—as long as those tools allow for open data exchange with other teams. Instead of forcing teams to use tools they don’t need or want, a better approach is to implement technologies that can bridge data and written communication gaps between teams that need to collaborate.

    HybridOps is ultimately a pragmatic, incremental, big-tent approach to digital transformation. Our most successful enterprise customers use this approach to roll out their digital transformation efforts, as opposed to the top-down, “Send everyone to Agile training,” enforced-compliance approach. In our experience, using the forced approach typically means teams end up using the language and processes of Agile development practices but actually fail to collaborate with others or make a meaningful impact on becoming more customer-centric.

    Measuring HybridOps Success

    All this talk about HybridOps is well and good, but how can organizations measure success in a HybridOps world? It’s actually very similar to other areas of a mature business: Leaders need to establish behavioral norms and measure outcomes (instead of outputs) relative to business needs.

    For example, it’s unnecessary to benchmark the mainframe team against the web team with metrics such as the number of deploys per day, tickets resolved per month or even system throughput. After all, a mainframe batch process that runs twice a week isn’t necessarily less operationally mature than a serverless function that can return an instant response.

    In short, when it comes to measuring performance, it all depends on the operational context and needs of the business—and it’s best to establish some common metrics that prevent overwork and burnout and use them across all teams.

    Culture, Culture, Culture

    Finally, one last word on culture. HybridOps can only succeed when senior leadership creates a high-trust culture. Blamelessness and fostering a learning culture are key here. Open communication and empathy for colleagues are important cultural values underpinning HybridOps that leaders need to establish and reinforce continuously. If leaders use ownership and control of data as a way to name and shame others when something goes wrong, a HybridOps approach won’t work.

    Ultimately, HybridOps is fundamentally a kinder, gentler route to digital transformation—one that’s focused on meeting people where they are and how they’re used to work. It encourages data-driven process improvements free of blame, avoids shaming people who aren’t “DevOps enough,” and creates high levels of empathy between technical professionals within an organization. It puts the focus on outcomes instead of outputs and favors collaboration and productivity over arguments about tools.

    — Julian Dunn

  • Building Amazing Apps, Part 3: Optimizing the Network

    Building Amazing Apps, Part 3: Optimizing the Network

    This is part three of a series of three articles on building and delivering amazing apps at the edge. Read part one here, and part two here.

    Introduction

    There are millions of apps available today, and it’s incredibly easy for any user to download and install any of them with just a few taps on a screen or click of a mouse. If you want to build and deliver an app that will amaze users, you need to be able to differentiate from the rest of the pack.

    Over the past 14 years, I’ve been working closely with the top companies delivering the most popular apps, helping them optimize their apps for speed and scale so users get a great experience. In this three-part series, we’ll explore the fundamental steps you must take to build and deliver your own amazing app at scale that will keep users coming back for more.

    We’ll break these steps down into three key areas:

    • Front end: Covers the parts of the app that end users interact with.
    • Back end: Looks at the required origin infrastructure to support the app, including databases, application, web servers and more.
    • Network: The glue that connects the front end and the back end.

    In the final article of this series, we’re going to explore four things you can do on the network to optimize your app and make it more amazing:

    • Distributed DNS
    • Protocol optimization
    • Latency optimization
    • Edge computing

    Distributed DNS

    The Domain Name System (DNS) is a critical part of making sure your clients can access your applications (in fact, it’s a very popular attack vector by hackers today because if your DNS is down, nobody can access your PPP). Distributing your DNS across many servers can help ensure that your DNS (and thus, your app) is fast and highly available, so you should use a DNS vendor that has a large DNS server network in a wide range of locations.

    Validating whether you have a properly distributed DNS infrastructure is rather easy. Just follow these steps:

    • Identify how many name servers your domain uses and their IP addresses. Ideally, you want a number between three and 12—the more the better. You can use command-line tools such as dig and nslookup to identify the name servers of a given domain.
    • Use an IP geolocation system to find out the physical location of the name servers. At this point, you can get a rough idea if those servers are close enough to your end users. Hint: Some CDNs offer diagnostic tools that can be scripted via APIs to automate IP geolocation.
    • If you want to be more thorough, you may want to run connectivity tests between the main locations of the users and the name server IP addresses to make sure the network latency—i.e., how long it takes for information to go back and forth between the client and the server—stays under 100 ms (the lower the better). Some internet providers and CDNs provide looking glass technology, which enables you to run connectivity tests that originate from servers around the world.

    Protocol Optimization

    Once your clients know where to connect, how they connect and the protocol used is something that shouldn’t be neglected. HTTP/2 is the modern, superior network protocol, as it uses a more efficient binary format, header compression, single network connection, stream multiplexing and server-push. Actually, I was very involved in the early years of HTTP/2 (the standard was approved in February 2015) and have since helped some of the largest websites on the internet implement HTTP/2 and still spend a considerable amount of my time testing the new protocol in all sorts of environments. I’ve shared my findings in talks at conferences including Velocity and in the “Learning HTTP/2” O’Reilly book, which I co-authored. In a nutshell, most sites can improve page load performance between 5% and 15% by just switching the protocol from HTTP/1.1 to HTTP/2, which is as simple as flipping a switch if your website uses HTTPS.

    To illustrate that improvement, I created a demo site that tests the download speed of many small images over HTTP/1.1 and over HTTP/2 and displays the differences.

    Figure A

    As you can see in Figure A, the content loaded eight times faster over HTTP/2 than over HTTP/1.1 on my mobile phone over an LTE connection. That’s a huge improvement considering how simple it is to implement HTTP/2.

    According to the HTTP Archive, as of June 2018, 20% of hosts support HTTP/2, but those hosts are responsible for 40% of all requests—meaning HTTP/2 powers some of the web’s most popular sites.

    However, as explained in the HTTP/2 Performance chapter of the Learning HTTP/2 book by O’Reilly, there are a lot of factors that can impact the benefits of HTTP/2. Some of them you can control, while others—such as network packet loss—are much more difficult to tackle and can impact HTTP/2 performance because HTTP/2 runs over a single TCP connection.

    Note: TCP stands for Transport Control Protocol and some parts of its implementation (e.g., slow to start and cumbersome network congestion algorithm) can impact HTTP/2 performance because all the communication with the server goes through a single TCP connection.

    The future of the web is HTTP/3, which uses HTTP/2 over QUIC (a newer and more efficient transport layer protocol). However, as of April 2019, HTTP/3 is still in draft state and hasn’t been approved as a standard.

    Ideally, your servers should monitor the network connection and use different network protocols depending on the current conditions. Certain content delivery networks (CDNs) offer this functionality. For example, to maximize throughput, a top CDN provider uses custom software on its edge servers to dynamically use different network protocols, TCP settings and congestion control algorithms, depending on the specific conditions of each individual connection the server makes with an end user. In short, using the optimal protocol makes your app faster and more amazing.

    Latency Optimization

    Latency is a physical limitation of nature that impacts the throughput on computer networks. You probably know that whenever you are outdoors and there is a storm with lightning, you can count the number of seconds until you hear the thunder to identify how close the storm is (and if you count less than a second, you better get inside!). In computer terms, latency is measured as the time it takes to send a network packet back and forth between two systems. This concept is known as round-trip time (RTT) and is typically measured in milliseconds. You can use network tools such as ping or mtr to easily measure the RTT between two systems.

    Latency has a huge impact on performance because the further away you are from the server you want to connect, the slower the communication will be. As a rule of thumb, you want to ensure your latency is well under 100 ms. The easiest way to achieve that is by leveraging the local device cache to avoid extra network connections to the server and using a CDN to put your server closer to the end user.

    Here is a graph (see Figure B) showing that latency plays a larger role on page load time than bandwidth. As you can see, doubling the bandwidth from 5Mbps to 10Mbps results in just 5% improvement in page load times, and any bandwidth increase over 10Mbps doesn’t make a big difference. Reducing the latency, however, drastically improves the page load times. That makes your app more amazing for your end users.

    Figure B

    Edge Computing

    If you are a developer or a DevOps engineer (or just love tech) chances are you are within the TOP 1% of world population in terms of mobile computing power. But things you take for granted, such as resizing images on a mobile phone, are going to take much longer for many millions of internet users who have less powerful mobile devices.

    So, what can we do if running logic at the origin causes delays because of the network latency and running logic on the client side may be too slow on less powerful devices? The solution is edge computing, which consists of moving the origin logic to a server close enough to the end users that latency does not impact performance. CDNs are in the best position to offer this proximity because of their natural distributed architecture; a CDN can set cookies, rewrite HTML and resize and deliver optimized images for the screen size of your users so those images don’t take a long time to display on low-end mobile devices with limited CPUs.

    Edge computing is the next step beyond cloud computing. You should try to use a CDN company that offers you the ability of running business logic as close as possible to where your users are, to ensure that your app is fast and can scale without impacting your infrastructure.

    Summary

    In this series of articles, we reviewed some basic things you should consider if you want to build and deliver amazing apps at scale. This is not a comprehensive list of all the things you can do but provides you with some of the most impactful areas for app improvement.

    — Javier Garza

  • Alerting Consolidation: What’s the DevOps Impact?

    Alerting Consolidation: What’s the DevOps Impact?

    Over the last 12 to 18 months, the monitoring and alerting piece of the DevOps toolchain has been going through some serious consolidation. Companies are bracing to compete with the world or getting picked up by larger DevOps players, making their product more appealing through integrations.

    In general, if such changes don’t impact your toolchain, I say ignore them. The exception is when it appears the entire submarket might need to get aligned to survive, because that means at some point your toolchain likely will be affected.

    So, to recap the source of this blog, in the last short while OpsGenie has become a part of Atlassian, VictorOps has become a part of Splunk and PagerDuty has filed for an IPO. It is likely the rest of the market will have to match these three or admit to eroding market shares. In a competitive market where customers are using a fraction of the available functionality of a given product, deeper integrations (like come from ownership) or bold road maps (like come from IPOs) can have an impact on what customers choose to use.

    Alerting—and monitoring in general—is still relatively new to its current incarnation, and unlike some markets there are still very real differentiators in it. Most alerting engines have a core of functionality built in, while a lot more functionality can be had through integrations with other products. Some focus on the network to garner the bulk of their alert conditions, while others focus on application performance and still more watch the infrastructure closely. While all do a bit of each of these things, they still definitely have a focus. That will change over time as the market either settles down or fragments. I’m hoping it will settle down; we have enough sub-markets in DevOps already.

    All I’m suggesting is that you stay in contact with your vendor of choice and watch the overall market. Some of the changes might create a situation in which an alternative is appealing, and that is worth looking into, but other changes might negatively impact your chosen solution, which is absolutely worth noting.

    If your product of choice is clipping along in a way that is acceptable/useful to you, by all means stay with it. There’s no sense changing a product simply because of possibilities. But being aware can help you navigate the market changes that are well underway and very well might hit you right in the stack.

    — Don Macvittie

  • 5 Practical Ways to Deliver Secure Software That Could Actually Work

    5 Practical Ways to Deliver Secure Software That Could Actually Work

    Almost every aspect of modern life is dependent on technology. As technology becomes even more advanced and pervasive, so, too, does the need for secure software.

    Today, even the tiniest breach at an organization could result in major loss of sensitive data. Therefore, it is crucial for both the reputation and proper functioning of the organization to have steady security measures in place.

    Below are five practical ways organizations can deliver secure software by prioritizing safety and maintaining a sustainable “security culture.”

    Organizations Build and Foster a Healthy Security Culture

    A security culture, just like any other culture, thrives when it is used actively. Effective security culture is a one-time investment that can reap major benefits. However, it requires effort from the organization.

    A viable security culture is based on four key features:

    • The security culture is disruptive in nature and brings about immediate change.
    • Security practices employed by the organization are engaging for everyone, not just the security department.
    • A proper reward system is in place for the people who actively take part in security regimens.
    • Investments made into the security culture are returned in one form or another.

    Ensuring that a proper security culture is in place takes care of the biggest problem in the development of software—humans.

    The establishment of a robust security culture helps humans in an organization more than it does the computers. It provides a proper framework through which employees at an organization can act to maximize security.

    Some ways to develop the security culture at an organization include:

    • Instill the belief into the employees that security-related issues are not just the headache of the security department; rather, the whole organization should work together to resolve them.
    • Focus on spreading awareness throughout the organization by providing employees the basic security knowledge.
    • Provide opportunities for advancements in security to team members who are more excited.

    Despite having a strong security culture in place, however, breaches may happen. A proper security culture can help the organization recover more swiftly.

    Acquire a Secure Developmental Life Cycle

    A secure developmental life cycle (SDL) provides a firm foundation to monitor the security practices in an organization.

    An SDL performs essential functions such as threat modeling, security analysis and requirements, and carries out security testing. The organization that acquires the SDL agrees to an in-depth study of their security on all the software and system releases.

    Microsoft, for example, offers a free SDL that consists of security practices that could help organizations regardless of their size or platform. This is especially useful to those organizations that have just started.

    Other benefits of having an SDL are:

    • Detects bugs in the software earlier in the development cycle, which is cost-effective.
    • Safeguards the interests of the stakeholders and investors, as it makes the business secure.

    Overall, an SDL minimizes the risks that an organization faces and helps in advancing it.

    Integrate Security Tests Into the Developmental Phase

    Organizations should introduce security tests in the developmental period; that is, when the code is being written or when the programmers check in on their codes.

    The introduction of security tests allows developers to correct their mistakes at an early stage, which effectively reduces the cost of resolving the problem. Developers actively get feedback, enabling them to design software with a smaller number of flaws.

    Moreover, tests conducted at the developmental stage save time and keep the disruption caused by the whole developmental process to a minimum.

    Have a Deep Understanding of What’s in Your Software

    Developers should work with security experts to understand the software and the applications installed.

    Knowing what constitutes applications—especially open source applications—is pivotal in patching any discrepancies that may arise.

    Along with a firm grasp on the software, developers must be aware of application security.

    Application security, or AppSec, teaches advanced lessons to the testers and developers within an organization and aids them in building secure products and services.

    Encourage Mentorship

    No security system is complete without a set of security experts who can train developers in specific methods and procedures. These mentors can be responsible for conducting security tests and furthering the advancement of secure software in an organization.

    Mentors can also provide a learning experience to the staff members and go the extra mile to make sure security is accessible for everyone.

    Conclusion

    Organizations need to maintain a standardized way of delivering software. The threats we face today, if  not dealt with, can have dire consequences.

    However, the solution starts at the very beginning and needs to be integrated into everything related to software, from education to the way employees interact with each other in the workplace. Only then can we rest easy knowing our software and data are protected.

    — Zehra Ali

  • Focusing on the True DevOps North Star: Continuous Improvement

    Focusing on the True DevOps North Star: Continuous Improvement

    When we look beyond the fundamentals of tearing down silos and establishing greater collaboration, communication and transparency, DevOps is a label assigned to a framework of best practices and technologies that organizations leverage to deliver systems faster, more efficiently and without sacrificing quality. The best practice within that framework is continuous improvement, which provides stakeholders with data and feedback to constantly improve their ability to deliver products that advance strategic business objectives. This is done through key performance indicators (KPIs) that align with the goals of the business.

    Continuous improvement thrives on a robust program of KPIs that measure key attributes of a successful development team in the context of what is important to your organization. These KPIs provide you with the opportunity to continuously evaluate your system delivery processes and supporting technologies, and identify opportunities to make changes that produce better outcomes. In general, all organizations should be continuously improving their system development and delivery against three primary KPIs:

    • Quality: The value and performance of software you deliver to customers.
    • Velocity: The speed at which you develop and deliver software to customers.
    • Efficiency: The ease (low resource consumption, minimal latency) with which you develop and deliver software to customers.

    For now, let’s focus on what’s required to continuously measure and improve against them.

    Continuous Improvement KPIs vs. Metrics

    KPIs provide baselines for minimally acceptable performance levels across critical areas that impact the success of your business. Metrics measured against these KPIs help development teams improve what they’re doing to support the performance of the business in light of its goals.

    There are hundreds of metrics available (escaped versus trapped defects, features deployed and mean time to X, to name a few). The problem is most organizations focus too much on non-business-related metrics and data points and end up measuring the wrong things, such as how many lines of code have been written. This data may be interesting, but it tells you nothing of how well or within what time frame the code was written, or how that affects the delivery of value to customers.

    Your metrics should align with the goal-oriented KPIs of your business. For example, if a goal is to increase the quality of software after an influx of customer support issues related to defects, you should measure how many defects are escaping and how many are being trapped in testing. However, the remaining challenge for most organizations is actually capturing this metrics data to accurately measure progress and continuous improvement against, for example, a quality baseline.

    Collecting Data for Continuous Improvement

    A large reason organizations struggle to capture the right metrics data is they rely on outdated project management tools and manual effort. Developers and other team members painstakingly capture and contribute metrics data through status reports and meetings. Project managers then spend the bulk of their time analyzing and producing even more reports to provide the necessary feedback to support continuous improvement.

    In a digital economy where fast beats slow, this slow approach of manual data collection constrains and negates the business objectives of increasing quality, velocity and efficiency simultaneously. Core to Agile is the production of working software and minimizing the amount of work not directly related to that endeavor. If you want to move to an agile, iterative world, you want to minimize activity or any work that’s not directly related to the software delivery effort.

    That’s why, for true continuous improvement, you want your tools to automatically produce the right metrics data to measure and continuously improve upon KPIs, rather than relying on developers to attend status meetings and feed project managers information used to manually build reports.

    Once you’re able to visualize this data with a modern dashboard-driven analytics tool, you can use that information to constantly assess and evaluate system development and delivery productivity, and help developers make behavioral changes. You will have the necessary information to tweak processes and tooling and better educate team members.

    For example, if your software quality drops below its KPI-defined baseline and your metrics show increased efforts utilized to resolve break/fix issues, you can make a valuable correlation leading to smarter actions to improve quality, such as tweaking or changing testing methods and possibly using more effective testing tools.

    In this way, continuous improvement becomes embedded in your software delivery architecture, as you’re no longer making gut-based decisions that require you to wait for an outcome and guess again. Instead, you’re using data to drive strategic, fact-based shifts in behavior as you develop software, with the knowledge that these changes will have a real impact on the business.

    Making Continuous Improvement Across Platforms

    Ultimately, continuous improvement must reach across platforms in your organization—from the cloud to the mainframe. Development teams should work to continuously improve system delivery across all development platforms.

    The KPIs mentioned must apply to the entire development team and business, not just developers on one particular platform or skill set. You want to identify KPIs that are critical to the successful delivery of systems that support your customers, employees and business partners.

    Now that we have covered the importance of continuous improvement through the use of system delivery KPIs, stay tuned as we explore the individual topics of quality, velocity and efficiency at a deeper level in subsequent articles.

    — Rick Slade

  • 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

  • 5 DevOps Trends Worth Knowing in 2019

    5 DevOps Trends Worth Knowing in 2019

    DevOps today is more than the buzzword it was 10 years ago. Back then, the idea of combining development with production in your IT infrastructure was not common; the logistics were nonexistent and most of the time businesses decided it was far too much effort.

    However, if the last nine years has taught us anything, it’s that DevOps is worth every penny businesses invest. It helps companies streamline production, keep customers happy and provide agile services to attract new audiences.

    But as with anything in the IT field, there is a paradigm of change. This article discusses some of the top DevOps trends happening now and how to implement them in your own system.

    Automation Will Be a Bigger Focus

    Automation has always been the way for businesses. Whether it’s speeding up the pipeline with machines, providing better response times for angry customers with chatbots or better inventory management with tracking and logging system, automation is behind it all.

    DevOps is no exception.

    But as with everything, there can be too much automation. The best thing to do is break down processes and find simple, redundant tasks that can save time if automated and apply the changes.

    The most important aspect of automating DevOps is to understand the six pillars in the DevOps cycle, which are:

    • Continuous business planning
    • Collaborative development
    • Continuous testing
    • Continuous release and deployment
    • Continuous monitoring
    • Collaborative customer feedback and optimization

    DevOps Assembly Lines: The Next Big Thing

     

    To track the development of your application, we have pipelines. These visually represent the product from its initial stage right through until final development and release.

    However, continuous integration (CI) is no longer the priority focus when it comes to effective monitoring and implementation. Continuous delivery and automation are a major part that businesses have already started delving into in 2019.

    This is where DevOps assembly lines enter the picture.

    Assembly lines are focused on bridging the gap between manual and automated tasks, ensuring there is no redundancy while providing several tools for teams to implement, to ensure apps are hitting the production lines as reasonably quickly as possible.

    Microservices Architecture Adoption Taking Off

     

    Microservices architecture may as well be that new kid in school trying to fit in. These smaller services compound into agile, implementable tools that DevOps teams can use to scale and test software over the course of weeks—not years.

    As you can imagine, this can help some businesses streamline their development and production lines, setting them way ahead of their original production estimates—which is never a bad thing.

    Implementing microservices into your DevOps team can also help companies focus on the runtime and efficient delivery of new development sources, without the hassle of creating dependency errors when something decides to bug out for no apparent reason.

    Security Needs to Step Up

    Cybercrime is on the rise—we all know that’s old news. But as a business, cybercrime can either make or break your sales and weigh down your DevOps team.

    That’s why more companies are hopping onto enterprise security options. Although there are third-party programmers for almost every situation you need, none of them have the same security levels as the tools from the enterprise version provides. Safeguarding both your company and your clientele.

    Riding the Artificial Intelligence Wave

    Finally, we have artificial intelligence (AI) and machine learning (ML). When you think about it, these two elements are literally the sum of everything we want in the DevOps community—the ability to crunch out hours upon hours of menial labor and saving your teams hours to focus on higher-priority tasks.

    The combination of AI, used to predict algorithmic influencers, and ML’s ability to adapt to new situations will be key for DevOps teams to get to the next level in 2019.

    — Gil Artmoore

  • Digital Transformation: Coming from Behind

    Digital Transformation: Coming from Behind

    For many years, enterprises have been in a race to digitally transform how they work through the digitization of all areas of their business, to reduce costs and business frictions through creating efficiencies and delivering increased value to their customers. While many organizations have attempted a transformation, few have been successful.

    Research from the consultancy McKinsey & Company finds that less than one-third of transformations are successful.

    How do organizations that find themselves today, perhaps after several failed transformations starts or having procrastinated getting started, get themselves back on track before they find themselves too far behind the competition to ever hope to catch up? We reached out to several experts to find out.

    First, many of those advised organizations that currently find themselves digital laggards should not rush into a digital transformation out of fear of missing out. “Don’t pursue digital transformation with a FOMO mindset,” said Andy Lin, senior vice president of strategy and consulting at Nexient, a software services provider. “Approach it with clear, measurable business results in mind, such as increased market share or increased revenue. Focus on how the end state of your transformation—business capabilities, technical capabilities, digital experience capabilities and similar—will make the biggest impact, and prioritize accordingly,” he said.

    Research from business consultancy West Monroe Partners, which ranked respondents by maturity, found 21% of respondents are digitally mature and 17.9% as very digitally mature. There remains a sizable percentage, 35.9%, who are either not digitally mature at all or slightly digitally mature.

    Trailing in digital maturity likely means those organizations find themselves feeling the pressure from some constituents: shareholders, customers, competitors and others, said Justin Rodenbostel, vice president of delivery services at digital transformation agency SPR. “If pressure is coming from lagging customer engagement, then one should become more familiar with customer desires through research or analyze how other industries are innovating and transforming,” he said. “Pressure from competition might require competitive analysis, market research or research into applications of potentially disruptive technologies,” Rodenbostel advises those who are trying to identify where they should focus on their catch-up efforts.

    Scrum.org CEO and product owner Dave West agreed: “Enterprises embarking on a digital transformation should look at their business strategy, their customer base and start with that; building teams that align to the customer, empowering them to drive technology and business decisions to make that customer successful.”

    Also, when they set a course, enterprises need to be sure to set goals to be set to such business outcomes as well, said Nick Polachek, senior principal strategy for Maven Wave. Instead of prioritizing technical results, such as building an enterprise DevOps pipeline, it’s better to focus on results associated with business-driven outcomes, such as improved customer experience. “To prioritize effectively, you need to understand business drivers and divide technology initiatives into attainable slices that create real business value and quick wins,” he said.

    West Monroe found many attributes—from the use of digital in sales to leveraging data—that organizations should prioritize based on their digital maturity. “An organization can fast-track its maturity by prioritizing certain characteristics over others, regardless of industry. For instance, those with the lowest maturity should prioritize innovation that addresses customer pain points and those with the highest maturity should prioritize best-in-class cybersecurity. More accelerators can be found in our research,” said Kyle Hutchins, senior director at West Monroe Partners.

    Finally, as the organization attempts to increase its digital transformation maturity, others advise organizations prioritize their digital transformation efforts that will get widespread support throughout the enterprise—which usually translates to initiatives that will increase sales. “Since most organizations are designed to support sales efforts, prioritizing transformation within the sales organization is an effective way to motivate the organization to transform,” said Craig Besnoy, program director and digital strategy consultant at Mindtree, IT services provider.

    Still, and this could be why so many digital transformations fail, a sizable percentage of organizations—41%, according to research and strategic consulting firm Altimeter—make investments in digital transformation without ever seeking the guidance from thorough customer research.

    — George V. Hulme

  • SolarWinds IT Trends Report 2019: Measuring the Skills Priority in DevOps

    SolarWinds IT Trends Report 2019: Measuring the Skills Priority in DevOps

    Although historically technology professionals were among the most adaptive specialists in the job market, a recent survey from SolarWinds found that DevOps teams, web product managers (WPMs) and developers lacked confidence in their current ability to effectively manage their current environments while engaging in future technologies. This balancing of current trends with future innovations is a necessity of having any technical role, as things change quickly in technology.

    SolarWinds recently published the latest edition of its annual IT Trends Report, IT Trends Report 2019: Skills for Tech Pros of Tomorrow, which explores confidence, current and future skill sets, career development and barriers to career success to reveal how DevOps teams, developers, WPMs and the businesses they serve can better manage future technology realities. How do these tech pros personally feel about their current and future skill sets? Coinciding with SolarWinds Cloud Confessions: The Trouble with Troubleshooting,the IT Trends Report found that tech pros have an appetite to prioritize career development on a weekly basis, but are hindered by factors such as time and cost. How can they prioritize career development while confronting the barriers to career success and develop the skills necessary to make future tech implementation a reality?

    The DevOps findings are based on a survey fielded in December 2018, which yielded responses from 100 DevOps practitioners (teams, developers and WPMs), managers and directors in the United States and Canada from public and private-sector small, midsize and enterprise companies.

    Among many other key findings, this year’s survey revealed:

    Most tech professionals in DevOps, web product managers and developer roles are not fully confident they have all the skills needed to manage their environments into the near future, especially when it comes to emerging tech. 

    • 75% of all DevOps teams, developers and WPMs surveyed are not “completely confident” in having all the necessary skills to successfully manage their IT environments over the next three to five years—even though 98% have worked to develop a skill over the past 12 months.
    • When it comes to the idea of implementing or managing specific technologies, emerging tech is a pain point (despite how much mindshare these buzz-worthy technologies get in headlines). The top three technologies DevOps teams, developers and WPMs feel unequipped to manage with their current skill sets are:
      1. AI (55%)
      2. Blockchain (50%) and quantum computing (50%)
      3. Machine and/or deep learning (45%)
    • According to the Gartner list of strategic technology trends that have the potential to disrupt and are on the verge of becoming more widely used in the next five years, AI, blockchain and quantum computing all rank in the top 10.
    • There is a great opportunity for DevOps teams, developers and WPMs to increase their knowledge of these technologies and to have productive conversations with businesses on the reality of implementation in the near future.

    DevOps teams, developers and WPMs will continue building skills in daily operations with an eye toward areas such as data science. 

    • In the past 12 months, DevOps teams, developers and WPMs have prioritized skills in coding and scripting (54%), systems and infrastructure management (43%) and database management (41%).
    • In the next three to five years, the top two skills developers and WPMs plan to develop are security management (45%), data science and analytics (41%).
    • DevOps teams’, developers’ and WPMs’ instincts are correct when it comes to the top skill set area as they’re expected to see continued growth. Gartner research analysts estimate that global revenue for the information security market will grow at a compound annual growth rate (CAGR) of 7.8% between 2017 and 2022, reaching $143 billion in constant currency terms.
    • Hybrid IT deployment monitoring and management rounds out the top three skill sets DevOps teams, developers and WPMs plan to develop in the next three to five years.
    • Gartner also predicts that the worldwide public cloud services market will grow by 17.33% in 2019, going from $175.8 billion in 2018 to $206.2 billion this year.

    DevOps teams, developers and WPMs say cloud and/or hybrid IT, big data analytics and AI are the key technologies for career development, which will help achieve higher goals such as innovation.

    • DevOps teams, developers and WPMs say the most important technologies for their career development are (by weighted rank) aligned with the top three technologies for organizations’ transformation over the next three to five years.
      1. Cloud and/or hybrid IT (59%)
      2. Big data and analytics (55%)
      3. AI (54%)
    • When it comes to career development goals over the next three to five years, DevOps teams, developers and WPMs will look to prioritize (by weighted rank):
      1. Technology innovation (49%)
      2. Programming, coding and/or scripting (33%)
      3. Data analytics and/or data science (38%)
    • Management/leadership skills (people management) and IT security protocol and/or processes round out the top five career development goals for the next three to five years.

    DevOps teams, developers and WPMs have an appetite to prioritize career development on a weekly basis but are hindered by factors such as time and cost.

    • Nearly 8 in 10 DevOps teams, developers and WPMs (79%) say their day-to-day IT tasks extend into time earmarked for career development, with 20% saying this always happens.
    • This is alarming considering DevOps teams, developers and WPMs enjoy technology skills training, with 49% finding it informative, 32% saying it’s engaging and interactive and 27% reporting it’s not long enough.
    • Currently, DevOps teams, developers and WPMs engage in IT skills training and/or career development programs ranging from a few times a year (25%) to monthly (23%) and weekly (19%); however, if there were no schedule or workload restrictions, most (42%) would prefer weekly training.
    • Developers and WPMs cite time and availability (48%) and cost (25%) as the biggest barriers affecting their current ability to participate in IT skills training and career development programs at the frequency they would like.
    • When it comes to their primary sources for training, DevOps teams, developers and WPMs turn to:
      1. My organization and/or coworkers (20%) and online communities/forums (20%)
      2. Industry events/trade shows (17%)
      3. Vendor training sessions (16%) and industry publications (16%)
    • However, the ideal delivery format for IT skills training according to DevOps teams, developers and WPMs is (by weighted rank):
      1. Self-guided online course
      2. In-person workshop/user conference (full-day)
      3. Webinar

    Final Thoughts

    For tech pros to continue helping businesses revolutionize current technology while proactively adapting for future disruption, it is imperative that business and technology leaders provide the training that tech pros seek, through courses, self-guided training and webinars.

    SolarWinds 2019 survey results emphasize the importance of empowering tech pros through training and focusing on career development. Emerging tech should not be a pain point for these tech pros—rather, they should have the opportunity to embrace strategic technology trends and have productive conversations with businesses on the reality of implementation in the near future.

    2019 is the year of integrating career growth, skills development and business transformation to empower tech pros with the skills necessary to help lead the business they support into the future of tech innovation.

    — Joe Kim

  • DevOps Chat: Computing on the Edge, with Swim.ai’s Simon Crosby

    DevOps Chat: Computing on the Edge, with Swim.ai’s Simon Crosby

    Simon Crosby has made a career of technology on the edge. From leading the charge with the Xen hypervisor to microVMs with Bromium and much more in between, Crosby has led some of the most innovative technology developers in the industry.
    He is now the CTO of Swim.ai which is literally bringing computing to the edge (almost an anti-cloud). This approach promises some revolutionary capabilities.

    If Simon is involved, there is a good chance it will succeed as well. Have a listen to what Simon is all about now.

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

    Transcript

    Alan Shimel: Hey, everyone this is Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and we’re here for another DevOps Chat. I’m really lucky to be joined by an old friend of mine for this chat, none other than Simon Crosby who is the CTO of a hot company out there called swim.ai. Simon, welcome.

    Simon Crosby: Thanks, Alan. It’s great to speak to you again.

    Shimel: Thank you. It’s actually my pleasure. Simon, maybe we have some young ones in the audience who maybe aren’t familiar with the one and only Simon Crosby. Why don’t you give folks a little background of how you came to be here today? Little bit of _____ –

    Crosby: Well, I was lucky enough to cofound a company called “XenSource,” which built and maintained the open-source Xen hypervisor, which was – so XenSource was bought by Citrix, but then went on to fame because we built Amazon AWS. And then on, from there, I then cofounded a company called “Bromium,” which used micro-virtualization to do security. And that has, funnily enough, turned also into Amazon’s micro-virtualization, which they very recently open-sourced, as well as the micro-virtualization in Azure.

    Shimel: So, in many ways, you’ve given birth to so – “given birth to”? – you’ve helped launch so many of the key technologies that are powering the cloud today, right?

    Crosby: It’s fun.

    Shimel: Yeah. You know, I think a lot of people tend to think hypervisor, VMware, and they forget, really, how important Xen was and still is.

    Crosby: Still is. It still has more VMs than any other hypervisor on the planet.

    Shimel: Absolutely. And then Bromium too – I mean, Bromium micro-segmentation, micro-perimeterization, whatever you wanna call it, again, was a – I mean, it was really a defining moment, you know? It was a –

    Crosby: Yeah. So I –

    Shimel: – _____ approach security.

    Crosby: So what Bromium does is every single task on the OS, every tab in your browser, we document your residency – its own little micro-VM.

    Shimel: Right.

    Crosby: And those things are tiny. And so if bad guys show up, it’s _____ _____. That technology has gone into Windows 10. It’s coming out in stages from Microsoft and it’s also available in Azure and in AWS.

    Shimel: Fantastic. But enough about that. We’re here to talk about SWIM.AI. And I’m gonna assume that most of our audience, probably, has not heard of SWIM.AI. They may get from the title that it is based on SWIM, but they may or may not even know SWIM. Why don’t you clue us in, Simon?

    Crosby: Well, the name is kind of a clue – it’s “software in motion.” We’re focused on the edge – in fact, intelligent edge computing – and so I’m gonna bend your mind a bit with a definition here. We’re all familiar with cloud and cloud computing as a set of abstractions for building stuff, not as a place, right? So, when we think of it, I’d like you to think of edge computing as needing a set of abstractions. And I think the current abstractions we use for cloud don’t apply very well at the edge. So let’s think of edge computing as a new set of abstractions, the ones that we need to deal with the world, which is generating more data than we can ever hope to store. And so what are the abstractions to do intelligent computing on that?

    Now, when we talk about edge intelligence, I mean, I guess four things: first of all, self-training and inference; analytics; any form of query – MapReduce, relational graph cap query, or any old other thing that you might wanna throw into data to analyze. And the key challenges with the current paradigms, the cloud world, which has been so tremendously successful, is really three things: REST, stateless computing, and the notion of a database. And all of these things are vital for all of the apps that we know and love today, but they completely screw up everything that you’re trying to do at the edge.

    So just think about this way: if I have an event coming of some sensor at the edge and I throw it up to an AWS Lambda thing, which then goes and looks up the old value in a database, does some computation and puts a new value in database, you know, that’s probably taken 100 milliseconds, 50 milliseconds maybe. If I’m running towards the edge in a distributed application, that’s tens of billions of CPU cycles.

    Shimel: Okay.

    Crosby: And so this notion of forgetting everything, which is really is focused scaling out the cloud, is terrible at the edge. What you want is a STAPLE model. And so STAPLE computation is fundamental in the edge – anybody who’s written a device driver knows this – and distribution is fundamental. Computing on data as it is generated, which means learning on the fly, analyzing on the fly, are fundamental. Okay? So not storing things on disks and pulling it off later because then you’re analyzing past data and you can only reason about the past. And we have to reason about things as they happen and respond in real time.

    Shimel: You know, what’s interesting about this to me, Simon, is – so I guess it’s gotta be, what, 2004, 2005, we start really seeing the cloud go mainstream, if you will. And I –

    Crosby: 2000 – you know what? AWS is beginning of 2006.

    Shimel: Okay. So fair enough.

    Crosby: Oh, but Salesforce, obviously, is a long time ago, but there you go.

    Shimel: Yeah, but, you know, this thing “the cloud,” right, and how it kind of exploded on the scene. And your company sort of started in ASP, back in the late ’90s – it was hosting Lotus Notes before there were hypervisors and clouds and _____ bandwidth. But, anyway, part and parcel of the cloud, though, was this notion that there would be this centralized – if not, but it would be distributed – sort of center where certain computation and hosting, like database, et cetera, would – and storage – would happen at that nebulous cloud. But there was always supposed to be the other piece of it, the edge. Right? There was the cloud and the edge. And we got so enamored with the cloud and so much happened with AWS and Azure and Google and a million other clouds out there, hybrid and all privates, we forgot about the edge for about –

    Crosby: Well, I think –

    I mean, I wanna be a little bit generous here. I think job one was to get enterprise IT out of bring in IT. In other words, get out of running exchange _____ _____ use things like Boomawipe because, gosh, let them run – let somebody else run their stuff for you. It’s not mission-critical. So the trillion dollars of traditional enterprise IT needs to get pushed to the cloud, and that’s happening at a huge pace today, and you see the winners emerging there. But there’s another trend which is happening and that is that, well, if you look at ARM, you know, ARM is licensing 20 billion cores a year.

    Shimel: Wow.

    Crosby: That’s a big number of CPUs. And every one of those is gonna be connected and generating data. And so that is a trend which is caught up. It’s because everything is smart now, right? You can embed these cores in anything. And so, when you deal with a world which has got that much data coming out of it, we have to do something other than simply save everything in a big data store and think about it later because there will never be a later. There is so much data coming out. And so there is a fundamental requirement that we process this data on the fly. I wanna introduce you a slightly mind-twisting thought. There is going to be so much data that things have to write their own programs. There aren’t enough humans to write programs for the things, right?

    Shimel: Yeah, no, I agree.

    Crosby: The things generating data will learn experientially, a little bit like you do – okay, you form a hypothesis about the world; you see the way the world develops; and then you change your hypothesis – so things will do that and they will learn on their own data. And, in “learning,” what I mean is you might – they’re writing a program, effectively, these things, right? So the program might be the wait of a DNN or something, and you might not understand what it means, but, when they have absorbed enough data, they’re really good at understanding their world and predicting the way it will evolve around. And that’s the way the world is going, that things write their own programs.

    Shimel: You know, I had a conversation with a guy named Luke Kiely, about two or three years ago. Luke was the founder and CEO, at the time, of Puppet. And he had a similar thing – he said, “Alan, it may not be this year, next year, five years or maybe even 10 years or more, but there will come a time where the software needs to write its own software.”

    Crosby: Yeah.

    Shimel: But, you know, it just – the humans are the bottleneck. Right? The human is the resource constraint.

    Crosby: Well, actually, I mean, they’re – we’re on DevOps podcast, but, you know, there will never be DevOps for my younger _____ _____ _____ _____. I’m telling you, there just will never be that. There aren’t enough people to do this, right? And so we have to back up –

    Shimel: Go ahead. No, no, you go on ’cause I agree with you. I mean, the _____ – I mean, the human is the single – just like in security, a lot of times, it was – that was the problem. [Chuckles]

    Crosby: Yep. No, that’s right. And so more automation is key. By the way, there’s another skillset which I think is hypothesized too much, and that is data science. I mean, programmers are rare, good programmers rarer. Data scientists? Good luck trying to find one.

    Shimel: You are not kidding.

    Crosby: Hard to find, right? And so there is this workflow which both Amazon and – well, Amazon, Microsoft, and Google posit, which is this: collect all the data; somebody builds a model, trains the model, and then pushes this model towards the edge, where it can do inference. You know, that’s just hypothetical nonsense. Okay? It’s not gonna happen. [Chuckles]

    Shimel: Go ahead.

    Crosby: And, by the way, so, first of all, you’re gonna collect all the data and, by the way, they’re happy if you do that ’cause then you’re stuck.

    Shimel: Right.

    Crosby: Right? ‘Cause then you’re stuck on that cloud.

    Shimel: Exactly.

    Crosby: And then, you know, you gotta find this person to build a model and train it. That’s really hard. And if the data is wrong, then you get over- or under-fitting, and then you gotta push all that stuff to edge. Nobody knows how to do that. It’s just not –

    Shimel: No, they don’t. You know, I was talking – I guess it was maybe last week. A friend of mine, actually from this gym we go to – she’s a recruiter. She’s recruiting down in San Jose and they’re trying to get Hadoop folks, just basic Hadoop programmers. And, Simon, look, I know things are crazy in the valley. I think they were paying maybe $240,000.00 or $250,000.00 and they –

    Crosby: Unbelievable.

    Shimel: They can’t find them, though. They can’t hire them. There’s not enough people with that data scientist, with that type of big data kind of background.

    Crosby: There aren’t. And I think, you know, as we move towards a more real-time business environment, organizations are going – let’s posit a future for enterprise IT. Enterprise IT, as you know, today, it needs to change towards something where the gunk is dealt with by somebody else. And then enterprise IT needs to feed real-time insights for different components of the business to the stakeholders, so they can make better decisions.

    Shimel: Okay.

    Crosby: Yep. And whether that’s supply chain or employees or whatever it happens to be, we need to put enterprise IT into position to deliver real-time insights. And how are they gonna do that? That’s really interesting problem.

    Shimel: Absolutely. But there’s something else to what you said too, Simon, that I wanted to hit on and that is – you know, you mentioned – what’d you say? – ARM had 20 billion or licensed 20 billion CPUs?

    Crosby: Yeah, per year.

    Shimel: Per year. You know, to me, you look at Uber, right? Some people will argue, “Is Uber a software company? Is Uber a drive company? What is Uber?” What Uber really was is they saw a glut of resource, right? People had cars that they weren’t using all the time, that they could monetize. Right? To a certain extent, it’s the same thing here – the amount of computing power on the edge or potential computing power on the edge.

    Crosby: Yeah.

    Shimel: So massive. Right?

    Crosby: Yeah, it’s huge. And so let me give – you’re actually right – so let me give you a really shocking example. So we solve this problem of prediction of traffic and I’ll give you two ways of doing it. And my example is the city of Palo Alto in California.

    Shimel: Mm-hmm.

    Crosby: And so we get about four terabytes a day from Palo Alto. That’s bigger than Twitter.

    Shimel: Wow.

    Crosby: Bigger than all of Twitter. Okay?

    Shimel: Mm-hmm.

    Crosby: So you could take all that data and push it up to AWS Lambda, into a model, and then learn and predict. Okay? Cool. That’ll cost you about $8,000.00 a month. Okay? And learning at the edge, as the data streams off the infrastructure, we bought no new hardware and it costs us pennies.

    Shimel: Wow.

    Crosby: Okay? So I’m saying thousands of times cheaper than AWS. Okay? So REST, statelessness, and databases are my enemy, number one, and then you’re absolutely right – there is a ton of unused CPU towards the edge, out in this distributed real world.

    Shimel: Nature abhors a vacuum.

    Crosby: And if I have 10 billion spare CPUs, I mean, I can do an inferencing cycle on Raspberry Pi in the time that it takes a packet to get from the city to AWS.

    Shimel: To AWS and then coming back. Mm-hmm.

    Crosby: We’re done, right?

    Shimel: Yeah. Yeah. Hey, Simon, as I mentioned, the time goes really quick. I wanna focus, ’cause your marketing people appreciate it, Swim.ai. How can people engage? What do you recommend how do they engage?

    Crosby: Okay. So what is Swim? Swim is a platform for application developers that want to develop massively distributed, stateful, real-time applications. Okay? It’s a tiny, two-megabyte extension to JVM, okay, which deploys and replaces a huge stack of cloud-based stuff, including the analytics and learning software, the pipelines, Pub/Sub, all the databases you might want. Okay? So we replace millions and millions of lines of code with something very simple.

    And it’s an extension of JVM because, that way, we get architecture independence. We found ourselves running ARM and X86 and everything else, all at the same time. And all you have to do is define what’s in your data and then SWIM builds a model for you, trains the model, and does the inference and prediction. Okay? So, simple, right? So the goal here is to make it simple for somebody who is a competent Java programmer, can do a bit of the business of doing really complex analytical stuff on streaming data, towards the edge.

    Shimel: Excellent. And, obviously, the website is swim.ai, yeah?

    Crosby: Yeah, developer.swim.ai is where you’d go and download it and run apps and everything else. You can download the platform, as well as the example app, so, if you wanna do something like New Relic, download Swim, stick it in each one of your VMs, and you’re up and running in a flash.

    Shimel: Excellent. So, Simon, I think I already know the answer to this, but I’m gonna ask it anyway. You have – I mean, your reputation precedes you, your accomplishments. What got you really excited about Swim.ai?

    Crosby: You know, if you can deliver improvements in performance and timeliness, which are in the orders of thousands – not 10X, 1,000X, okay? – and really change the world in dramatic way, that’s really exciting. So let me just – let me give you a somewhat critical view of the cloud, right? The cloud vendors make huge margins keeping memory warm for lots and lots of copies of Windows or Linux. Okay?

    Shimel: Uh-huh. Okay.

    Crosby: And most of that is idle.

    Shimel: I got it.

    Crosby: Most of those things are sitting there, doing nothing –

    Shimel: Just waiting.

    Crosby: – while REST happens. And we’ve moved compute from binary into these ASCII-based REST interfaces with lots and lots of pausing. Okay, cool. And now you’re paying for it.

    Shimel: Yeah.

    Crosby: What I’m saying is that you can do that same computation really enormously cheaply, towards the edge, on stuff you already own. And that’s very interesting.

    Shimel: It really – and I could say, “Well, it’s sort of as expected.” Well, Simon, people can go to the website to find out more. You’re talking at any conferences or the company is _____ –

    Crosby: Yeah, so we’re launching Swim app at the developer week in Oakland, on Thursday.

    Shimel: This Thursday? Which would be February 21st.

    Crosby: Yeah.

    Shimel: Well, by the time this is up, that might have passed, but they can probably check it out there and see in the website. Well, Simon, if it’s anything like the other stuff you work on, this is gonna be great.

    Crosby: Thank you, sir. It’s a privilege to spend time with you.

    Shimel: We’ll be watching you closely. We wish you lots of luck. And, you know, living life on the computing edge –

    Crosby: It’s fun.

    Shimel: It is fun. Hey, man, it’s great catching up with you and best of luck, Simon.

    Crosby: Thank you, Alan. It’s great to speak to you again.

    Shimel: All righty. Simon Crosby, CTO of Swim.ai. Check him out, computing on the edge. This is Alan Shimel for devopsy.kinsta.cloud. Have a great day, everyone.

    — Alan Shimel