devopsy.kinsta.cloud

Tag: applications

Quick Base Makes Free Low-Code Platform Available for First Responders

Quick Base, a provider of a platform for building low-code applications, announced this week that it is making its platform available for free through Sept. 30 to first responder organizations that need to build applications quickly to address the COVID-19 pandemic.

Jay Jamison, chief product and technology officer for Quick Base, said it’s apparent first responders soon will need applications to track things ranging from assets such as ventilators to heat maps that show the number of patients in a geographic area relative to the number of intensive care units (ICUs) available.

Quick Base is also making available templates that can be employed to build the most common types of emergency response applications, such as ones already being employed by the City of New Orleans.

Examples of other applications that will be needed include the ability to track businesses in real-time that may be flouting COVID-19 restrictions or landlords that are evicting tenants despite emergency decrees, noted Jamison.

Most of these applications will need to be developed in days versus weeks or months. To that end, Quick Base is also making available to first responder organizations the expertise of its internal customer success staff as well as third-party consultants, he said.

In addition, Quick Base plans to certify many of these applications for distribution via its online store, which will make it easier for a first responder organization in one locality to leverage an application that has already been developed by another first responder organization.

In general, Jamison said first responder organizations will need to apply DevOps principles across their entire organization to adjust to highly fluid situations. Applications undoubtedly will need to be modified as processes evolve and new emergency decrees are declared, he noted.

The biggest challenge from an IT perspective is many first responder organizations lack the process expertise needed to build an application on the fly. Volunteers with IT expertise will be needed to work alongside medical experts, who will need applications that most likely will be deployed in the cloud but made accessible via a range of mobile computing devices. The chances all those applications will work perfectly when first deployed is almost nil, so timely updates to applications will be critical.

Of course, applications and IT processes are not always the first things that come to mind to combat a pandemic. However, the faster first responders can respond to changing conditions on the ground, the more lives that might potentially be saved. In some large cities, it’s probable first responders already have access to a range of applications that to vary degrees might scale to meet the current challenge. However, in smaller localities, the availability of such applications is nominal at best.

Quick Base is not the only provider of low-code and no-code tools for building applications, so there are plenty of options for building applications quickly. Whichever the platform employed, time is going to be of the essence. Outbreaks in Italy, Spain and China have already shown how quickly events can spiral out of control. If any new application is going to be relevant in any other emerging CIVID-19 hot zone, the work to build that application needs to start immediately.

— Mike Vizard

March 25, 2020
Survey Sees Massive Adoption of Microservices

Under increasing pressure to innovate faster, a majority (84%) of organizations taking part in a recent survey have already embraced microservices.

The survey, conducted by Vanson Bourne on behalf of API management platform provider Kong, polled 200 senior IT leaders in organizations with more than 1,000 employees. Among the results, 89% of technology leaders agree that companies that are not able to effectively support microservices will be less able to compete in the future.

The report also finds on average organizations are running 184 microservices, with 60% of respondents running 50 or more. The primary reasons cited for adopting microservices are improvements to security (56%), increased development speed (55%), increased speed of integrating new technologies (53%), improved infrastructure flexibility (53%) and improved collaboration across teams (46%).

Kong CTO Marco Palladino said the report makes it clear that just about every organization is on a journey to making a transition to microservices as part of an effort to reduce reliance on inflexible monolithic applications. Initially, that transition involves lifting and shifting monolithic applications in the cloud before decoupling functions using microservices, he said.

As part of that journey, Palladino noted, the survey also finds significant microservices challenges remain, including ensuring security (36%), integration with legacy applications (32%), the complexity of management (31%) and updating API documentation (31%).

Despite these concerns, however, more than 80% of survey respondents who have adopted microservices report that their organization performs well against metrics for development efficiency, the ability to use new platforms, collaboration across teams and sharing of services across applications.

Overall, a full 90% of respondents said securely connecting applications and ensuring performance at scale collectively represent one of the greatest technical challenges of the 21st century. Also, 71% said they believe that organizations would be out of business within six years if they fail to keep pace with innovation in their industry. For public companies, the urgency is even greater, with 39% reporting they believe organizations will be out of business in less than three years if they fail to keep pace with innovation. Overall, 57% of technology leaders feel organizations are concerned that they are at risk of competitive displacement.

Pressure on IT leaders is high as a result. Nearly three-quarters of respondents (74%) agree that a failed digital transformation effort will result in a missed promotion, lost bonus or even termination. The report identifies the top three priorities for IT leaders as improving efficiency (47%), reducing cost (41%) and increasing security (40%).

Technology leaders, however, continue to place the highest importance on the availability (75%), security (74%), performance (65%) and scalability (64%). At the same time, technology leaders are focused on faster development speeds (95%), increased collaboration (94%) and reduced deployment risks (93%) as key desired outcomes for adopting any new technologies.

The challenges most cited in terms of achieving those agility goals are the complexity of using multiple technologies (35%), lack of automation (32%) and reliance on legacy technologies (29%).

The survey also notes 83% of organizations are relying on open source software to become more agile. The most commonly used open source technologies are databases (64%), containers (48%), API gateways (41%), infrastructure automation (40%), container orchestration (37%) and continuous integration/continuous delivery (CI/CD) tools (36%).

In terms of cloud adoption, Microsoft Azure (43%) narrowly beat Amazon Web Services (AWS) (42%), with Google Cloud Platform (GCP) coming in third at 27%.

On the plus side, 78% of respondents said their organizations are increasing IT budgets in the coming year, with 27% of public companies expecting their budgets to grow 26% or more. Nearly 90% of companies will also be increasing headcount, with 56% hiring internally and 31% relying on more freelancers and/or outsourcing to meet hiring goals.

Hopefully, with that increased funding more organizations will be able to strike that elusive balance between stability and innovation.

— Mike Vizard

December 12, 2019
Virtual Instruments Aims to Meld DevOps, ITSM Worlds

Virtual Instruments today announced additions to an IT management platform that leverage machine learning algorithms to identify application drift and dynamically right-size virtual machines.

Tim Van Ash, senior vice president of products for Virtual Instruments, said version 6.2 of the company’s VirtualWisdom platform is part of an ongoing campaign to meld the traditional world of IT service management with best DevOps practices using an AIOps platform. As part of that effort, Virtual Instruments last month acquired Metricly, a provider of tools for monitoring cloud costs in real-time.

The latest update to that platform also adds tools to monitors, reports, forecasts and alarms against the capacity consumption rate of any application, while a capacity forecast alarm now allows IT teams to specify how many days, weeks or months they wish to be notified prior to potential capacity exhaustion occurring on any one node or cluster.

Finally, Virtual Wisdom 6.2 provides access to updated VirtualWisdom Proactive Dashboards that provide access to Smart Charts, through which the AIOps platform now supports annotation, linking and smart naming in addition to topology views that are specific to a set of IT infrastructure or an application.

Van Ash said the Virtual Instruments approach to AIOps is that it allows IT teams to respond to changing application conditions in real-time and set granular limits on how much capacity can be consumed by any particular application. For example, IT teams can ensure that specific applications are given a Platinum-level preference that prevents any other application from consuming resources allocated to that application, he said.

In general, Van Ash said Virtual Instruments is pursuing an application-centric approach to AIOps that will make it easier for IT organizations to optimize IT infrastructure capacity dynamically. Rather being overly focused on utilization rates and tracking events, AIOps platforms need to be able to address the entire IT life cycle as it relates to the value that IT environment has to the business, he said, noting today many DevOps teams are building and deploying applications with little regard or actual control over the service levels those applications need to achieve and maintain. The goal, he said, is to provide a single platform through which DevOps and IT operational teams steeped in legacy IT service management (ITSM) models such as ServiceNow can collaboratively achieve a common set of goals.

A day of reckoning is coming for proponents of DevOps and IT teams that have built sprawling IT environments employing ITIL-based processes. Those ITIL-based processes are not especially flexible, but they have been employed successfully to roll out applications at scale consistently. Advancements in AIOps should go a long way to bring the two schools of IT management together by making it easier to bend the available IT infrastructure resources to the will of multiple application developers trying to share a common pool of resources.

In the meantime, no one should expect AI to solve their problems magically overnight. It takes a while for algorithms to solve all their IT headaches. However, the days when the relationship between developers and IT operations teams could be described as mostly contentious soon may be coming to a merciful end.

— Mike Vizard

September 4, 2019
Speaking the Language of Applications
I arrived early to a meeting, and the pleasant security guard at AT&T suggested I take a look at their innovation museum while I wait. Among motion picture sound technology and life-size photos of switchboard operators on roller-skates stood a transistor prototype. The transistor was invented in Bell labs in 1947, and it changed the world. Steve Wozniak considered it the greatest innovation of all time in his 2014 article.

But almost nobody needs to think about transistors anymore. The transistor had to become transparent and abstracted, so the next generations can build great things in higher level. The transistor made a huge influence on our lives as an enabler, but if people had to keep talking about transistors it wouldn’t be possible.

Abstracting technologies is key to advancing to a higher level, making it possible to solve real business problems.

The language of a client-focused business is applications. If we want to make a business execute faster these days, we need to make the development and release of its applications execute faster. But one thing stands in our way: the infrastructure. Applications reside on infrastructure–they are installed on servers, bundled in containers, on cloud instances, in networks, using storage.

If we want to speak the language of applications, we need to abstract them from the infrastructure, and make the infrastructure transparent.

The concept of abstracting applications is what stands at the basis of every new approach to application development and release around us.
- Containers are all about abstracting services from specific infrastructure and making them mobile.
- Serverless takes it to the extreme.
- Public cloud makes it easier not to worry about owning physical infrastructure.
Technology screams, “Think applications, soon you will not have to worry about infrastructure!”

And yet, most of us mix applications and infrastructure in an unhealthy way when we try to automate them. It is unhealthy because mixing applications and infrastructure prevents reuse of automation assets and makes it very difficult to connect infrastructure usage to a business context.

Understanding how mixing applications and infrastructure is manifested requires looking back into the evolution of infrastructure and application automation.

The Evolution of Infrastructure: Manual Deployment and the Inception of Its Automation

In the beginning there was manual. We got a server; it was sitting on a shelf. We got the application artifacts, maybe on a CD or a USB stick. We installed the application on the server. Our application was ready for use. When we needed to upgrade, we went back to the shelf and installed the update on our server. It was very hard to make this operation faster.

This is where automation of applications and infrastructure started.

Behind any automation tool or standard stands a model. This model reflects how its creators originally perceived the problem they were trying to solve. It consists of the entities they defined as first-class citizens, the operations they wanted to apply on these entities, their attributes.

“All models are wrong, some are useful,” said George E. P. Box in 1976. This is true for automation models too. Automation models are usually nice and clean when we start off. But as the problems we try to solve transform, our models need to grow and adapt. Until at some point they are not useful anymore and we need to replace them with next generation modelling approaches.

The Configuration Management Model

Configuration management tools such as Puppet and Chef were originally built to manage application deployment and configuration on static infrastructure. This new approach to Ops optimized manually updating applications on servers. Better network connectivity made it possible for this model to thrive, with the ability to configure applications on servers remotely.

But within a decade we witnessed the fast rise of immutable infrastructure. Immutable infrastructure is an approach to deploying applications where the infrastructure components are replaced instead of updated. This approach somewhat pulled the rug from under the configuration management model. With each update or change, the application must be re-deployed. This forced adding dynamic infrastructure provisioning to the configuration management model. Combining infrastructure automation and immutable infrastructure concepts into the configuration management model is a difficult task, since this model was never designed to accommodate something like that.

The Infrastructure-as-Code Model

Pure Infrastructure-as-Code tools were built to provision infrastructure dynamically. Terraform is an example for an open source tool that does this well. This model is created with infrastructure in mind.

Whether we look into Terraform, AWS, CloudFormation or ARM templates, we will see the infrastructure is the starting point (defining network connectivity, VM instances and services) and the applications are an implicit addition. They are artifacts that happen to be deployed on and are tightly coupled to the infrastructure. We may look at a component that says “App A” but it actually stands for “specific infrastructure with app A installed on it.”

This seems natural, because it’s the same way it worked in the good old physical-infrastructure world: We fetch a box, we install something on it. We focus on the infrastructure, because this is our starting point. The application is the artifacts we put on the infrastructure and scripts we run after we provision it. Presumably, the application cannot live without something to be on.

Infrastructure-as-Code tools evolved the way open tools do–their base model was extended by the community because there was a need to automate applications deployment and not just infrastructure. But it is becoming difficult to extend this model to reflect a world where applications are built to move between clustered servers, and the starting point is no longer the infrastructure, but rather the application’s requirements.

Mixing Infrastructure and Applications

Trying to fit infrastructure provisioning and application deployment in a single model that was originally designed for just one of them creates issues. Infrastructure is lower level than applications. Applications reside on the infrastructure. The same app can reside on different infrastructure configurations. This critical relationship is completely flattened if you mix them.

Moreover, from a business perspective it is important to make applications explicit. It’s our product. Our website. Our mobile app. The applications need to be the center of the attention and discussion. This kind of modelling puts applications in the shade of infrastructure.

Four Great Reasons to Model Applications as a First-Class Citizen Right Now

The models we use today are broken, and it is time to evolve. No matter if your applications reside in containers, or on cloud instances, or include native cloud services or a mix of them. Applications should be a first-class citizen, and not some artifact installed as an afterthought on the infrastructure we started from.

The notion that applications should be abstracted from infrastructure doesn’t eliminate all the challenges of infrastructure provisioning and application deployment, but it creates a foundation for better and more scalable automation.

1. Achieve Application Re-Use

Modelling applications as a first-class citizen is the only way to make applications a re-usable element throughout the development and release pipeline.

If there’s one thing I learned in my automation journey, it is that if automation doesn’t get frequently and consistently reused, you don’t get value for your money.

2. The Path to Multi-Cloud

Abstracting application is also the best approach for moving application workloads between cloud providers. If everything starts from infrastructure, we need to start from scratch when we move. If our applications are abstracted and defined separately—this definition stays the same when we move, only the infrastructure changes.

3. The Path to Breaking Silos

The vision of Dev, Sec, and Ops all dealing with the same language (code) is wonderful. But bringing everyone to the same code pool is not always easy. Applications and infrastructure are not the same thing, even though we can code both. Mixing them makes them unnecessarily hard to build and troubleshoot. It forces us to deal with fuzzy boundaries when it comes to responsibility for this code. Basing automation on a model that organizes the world in a way the different stakeholders can understand it, can help overcome this barrier.

4. Connect Infrastructure to Business Needs

Infrastructure-as-Code is a huge breakthrough, but the bigger story is about making application development and release faster. This doesn’t undermine the importance of infrastructure; infrastructure is the foundation of everything. But if we want to solve business problems, we need to talk the language of the business, and that’s the language of applications. Our automation should be built in a way that reflects this.

— Maya Ber Lerner
July 26, 2019
Go Big: Scalability in the Age of DevOps

Achieving hyperscale is a work of technical art for any business. As companies grow and customers begin to rely more heavily on your service, ensuring reliability during peak business times is mission-critical. An enormous amount of work goes on behind the scenes to ensure scalability, and oftentimes it becomes necessary to redesign or rethink processes and systems to improve them as they face increased pressure.

When customer demand reaches its apex, it’s the ultimate test for any organization’s systems and processes; therefore, it’s important to prepare a comprehensive strategy that focuses on scalability, reliability and hypergrowth in a targeted, calculated and data driven methodology.

The first step on your path to hyperscale is forecasting and gathering data analytics around business and growth patterns for a full year to make smarter forecasts. Set aside time each day throughout the year to go over the allocation of your data and analytics, measuring them for accuracy to see how they stack up to your current predictions for that specific day. This may seem taxing and cumbersome when engineers have other priorities to work on, but devoting time to this in the early months of the year will help you be that much more accurate when it comes to predicting the needs of your customers and how you should go about scaling to meet those needs.

Especially during the holiday season, it’s important to have a minute-by-minute projection of how much traffic you expect and need. That’s where forecasting and an advanced data science model come into play. A common mistake made when it comes to scalability is not getting granular enough about the real pressure points for your systems. Having accurate projections and forecasts in place that feed into your data science model means you can better test your systems and production limits while gaining greater insight into meeting your scaling points. If you find fragilities ahead of time through this, you can assign your engineering team to fix them well in advance.

Another way to truly bolster your scalability efforts is by introducing an operability development model. This entails constantly deploying some controlled chaos into your systems to see how they really stack up and function under pressure, with the goal of up-leveling the capacity of both your operations and system growth. The operability development model allows you to really test the grit of your systems by squeezing the most out of them, prepares you to respond quickly and methodically should the worst case scenario occur and sets you down the path toward continued performance growth and scale.

From here, you’ll want to institute a preventative maintenance model. Think of it like getting an oil change for your car. Instead of waiting until the very moment you need your software to perform exceptionally, start taking a look at the little things that could or are causing problems ahead of time and fix them on a monthly or quarterly basis. A preventative maintenance model helps you inspect, adapt and solve these little nuisances before they become serious problems, granting you the cleanest operating environment possible.

Scalability is king, but availability and reliability are arguably just as critical. Improving availability means reducing latency and getting as close as you can to where your customers utilize your services. This can be achieved by deploying locations around the world to make connections much faster and services more independent. To maintain reliability, you should have processes in place that can quickly respond and offer support to customers 24/7 to maximize consistency and performance.

Another strategy to consider—if it makes sense for your business or if you’re evaluating cloud providers as a growth option—is to double down on your efforts by re-architecting your platform and systems as cloud native from the ground up to support greater levels of scalability and cost efficiency. By going cloud-native, you can achieve independently scalable services so that you don’t have to scale all of your services together. This means your engineers and developers don’t have to spend way too much time figuring out where issues and fragilities occur.

A platform architected as cloud-native allows you to leverage microservices and containerization, creating an environment with more reliable, self-healing, high-tenancy and auto-scaling features that take the most advantage of your hardware and services. An added benefit of a cloud native platform is that you can use your data to find the most opportune times to both scale in advance and descale based on performance and customer expectations. The efficiencies that come from re-architecting as cloud native enable engineers to spend more time on automating software and the delivery pipeline, which is a huge boon for scalability.

At the end of the day, a well-thought-out preparation strategy for mass scalability makes the whole process much more exciting and obtainable. It also greatly reduces lead-up anxiety by getting a head start on planning so that you have more time to sit back and enjoy the fruits of your labor. Lastly, a yearlong scalability strategy enables you to experiment and try new things without the fear of failure. Testing new approaches ahead of time to see what does or doesn’t work will only help you learn and make your scalability efforts that much more effective for the future as your company continues down the path of hypergrowth and hyperscale.

— Jamie Tischart

January 18, 2019
So Many DevOps Tools, So Little Time
I’ve received thousands of emails, ads and sales pitches for tools for every stage of the app life cycle, from automating infrastructure buildout to release planning to building and testing, to delivering applications. If you’re building or rearchitecting an application, you have a surfeit of choice of DevOps tools.

Ironically, when an organization invests in various DevOps tools, it can lead to disconnected teams that are siloed by tooling. Gartner calls this “disconnected islands of automation.” In addition to a culture problem, it can lead to major incidents and downtime.

You can’t tool yourself into DevOps. But here’s how to make sure you’re not hurting your team with the wrong tools.

Step 1: Process Before Tools

Find out what problems you need to solve, then find tools to fit that need. It sounds simple, but many companies do the opposite: they’ve already picked the tool, and then use it to attack every problem.

“If all you have is a hammer, everything looks like a nail.” If all you have is one or two main tools, every problem gets fixed by those tools. Our team has been guilty of this, too. When you get really good at one tool, such as Puppet or Chef, the answer to every question is inevitably Puppet or Chef.

For our team, the fix has been to create process and architecture diagrams without tool names. Instead, we describe what needs to happen at each stage. If I know I’m building a long-running virtual machine, I know I need a configuration management component. Once we agree on the process, then we discuss tools.

Engineers are practical people who are trained to be constrained by the tools we use. To break out of this mindset, write out your desired code pipeline without tool names, even if you “know” the DevOps tools you’re going to use.

Step 2: Give Equal Priority to Infrastructure and Application Tools

A software company recently told me an unhappy story: The company spent years perfecting its continuous delivery pipeline and everything worked together like clockwork. Developers could test and run code in minutes.

The development team knew how to push code, but nothing was reachable in their region. Some of its delivery tooling was running in the same cloud region, so even though other regions were up, the tools the team wanted to use to perform failover weren’t available. When the team went to fail to DR, the configuration for its DR infrastructure had not been kept up to date with production, so instance sizes were not sufficient to run the application.

The moral of the story here is that your infrastructure and application need the same level of automation and agility. Even if you have a very mature CI/CD pipeline with gating, approvals, linting, etc., if you don’t have that same discipline and tooling around your infrastructure stack, then you’re equally down. You should have the ability to move your application from one region to another (and if you’re really ambitious, from one cloud to another). Also, if you’re not incorporating application development into infrastructure development, over time your infrastructure will grow out of date.

You should be asking questions such as:
- What steps can we take to automate infrastructure provisioning?
- How can we continually test failure?
- What steps can we take to survive a platform failure?
Step 3. Integrate Infrastructure and Application Tools

The best way to survive a platform failure is to continually “practice” building out entirely new infrastructure and application stacks—as one continuous process, not as two different activities.

Here’s one extreme example. The team at Logicworks recently worked with a large enterprise software company that was launching an internal product with a custom deployment pipeline. The pipeline included dozens of parallel automated and manual tests, each in a separate development environment. When a new deployment to the development environment occurs, a new set of 45+ dev instances must be created that has the new version of code; when the test is finished, the instances must be terminated. This means that instances in their environment rarely last for longer than 24 hours, and over the course of a single week, hundreds of instances are terminated and rebuilt.

As you can imagine, this company has never experienced an infrastructure outage it couldn’t recover from, since it already recover from “failure” hundreds of times a week. This is the true meaning of immutable infrastructure: virtual instances are disposable and once you instantiate the infrastructure and code, you never change the instance. This way the infrastructure never strays from its initial, known-good state, operations are simplified and the system is so good at replacing itself that failure is a non-event.

Ideally, infrastructure automation and application automation are not different stacks with different teams, but the same stack with the same level of destructive testing, so that an advance in your application needs to be tested against the current state of your infrastructure.

Summary

The constant release of new DevOps tools and features can be overwhelming. But the biggest challenges for your DevOps team probably have nothing to do with CI/CD tools. I have found that it’s easy to overemphasize tools and deprioritize crucial (albeit less glamorous) automation components such as infrastructure templates and testing.

Your developers are constantly looking for new libraries and experimenting with new languages and tools for your applications. You need the same level of attention and testing in your full infrastructure and application stack. This will make you choose better application-level tools and prepare you for failure.

— Jason McKay
November 16, 2018
Solving the ‘Automagical’ Apps Automation Problem

The DevOps Revolution started with a handful of simple principles. A key one was that systems should be managed by code, not by humans, to eliminate complexity and ensure better security, compliance and scalability. To manage compute infrastructure at any scale, the process should be automated with logic captured in code. And, ideally, automation also would apply as you move up to the stack to middleware and applications layers.

Unfortunately, it’s not that simple. In fact, automating applications turns out to be way more complex than automating server deployments. For this reason, we need a new approach to managing applications and infrastructure. Managing servers and lower-level environments could be simpler, but existing bottom-up methods work fine. Managing applications, however, must come from the top down. That is, applications should come with everything they need to be successful: configuration, packaging, discovery, scaling requirements and more. And that just isn’t how we have historically built software. Applications are built on layers and layers of dependencies that connect all the way down to the system level. So how do we break the mold and make an application “self contained?

Thousands of Apps with Millions of Dependency Permutations

By automating the Linux and Windows server ecosystem and a small number of derivative operating systems we can cover roughly 95 percent of operating systems, and the series of functions that are common across them. The complexity arises when we try to lay that matrix upon the array of applications that exist in the real world of deployment and production. In smaller companies, you usually have at least a dozen applications and often more. In larger companies, you are dealing with hundreds or thousands of applications.

This melange spans bespoke apps running in legacy languages, proprietary third-party software and more modern open source software. There are literally millions of permutations that must be automated across dependencies, along with security and compliance regimes. In the world of Kubernetes, for example, each container requires its own Sidecar that contains configuration and management information. Kubernetes Sidecars, however, don’t have robust automation capabilities and quickly sprawl out into a mass of human-defined management instructions that can easily conflict or break down under stress.

The upshot of this? Today we can write a small amount of code that can effectively manage hundreds of thousands of servers for Facebook. This is true to basically infinite scale. But to automate management of Facebook’s software has injected orders of magnitude more complexity.

Fear of Application Complexity Killing Cloud Migrations

This dichotomy has led infrastructure automation to go sideways; organizations have adopted inauthentic automation coupled with departures from the real ideals of DevOps and agile methodologies. Many companies just aren’t realizing the true benefits of infrastructure automation because they are doing something that is needlessly complicated and may have characteristics of automation but in fact is even more complicated. Thus, they have lost the value of the word and merely exchanged one complexity for another.

Similarly, many application development teams are doing what they call “ad hoc” infrastructure automation as DevOps teams avert their eyes and pray. Translation? A roll-your-own mishmash of tools to manage containers or VMs, applications and all the dependencies from the top to the bottom of the application runtime environment. What this really translates into is a human executing an ever-changing set of narrow paths against an individual server—a recipe for chaos. This chaos is why the majority of our customers believe infrastructure automation is a critical step to achieve agility but a smaller subset have fully embraced it.

It’s also a major reason why many companies that would love to migrate to the cloud have not yet done so. Managing the repackaging and movement—the “lift-and-shift”—of all their applications is a daunting prospect that they rightly believe will be far more difficult than simply switching from bare-metal or VMs to instances in AWS or Azure or Google Compute Engine.

Now, we don’t need to throw the baby out with the bathwater. The automation of operating systems and VMs and containers works just fine and is actually a tremendous improvement on past efforts. In fact, we could easily operate there with a smaller set of features and capabilities than we have to date. But applications must be managed from the top-down to accommodate the inherent complexity of managing so many more moving parts.

Enter The New Paradigm: Top-Down Application Management

Top-down application management works in a fundamentally different way, Rather than rigid configurations and choices about what an application should do, modern application management tools for DevOps teams should ask what an application needs to succeed and do its job well across the entire life cycle, from development to production to retirement. These tools should automatically discover changes in dependencies of an application stack, from front end to middleware to database and load-balancing and security.

If there are changes in these dependencies or other critical factors, then those tools need to automatically rebuild and test the applications, and have them ready to deploy either as a canary or directly into production if the changes are minor. For example, if a new SSL patch is published and a DevOps team updates its underlying infrastructure, then the application management toolchain should recognize which applications need to make which changes, and how that might affect both upstream and downstream dependencies. Ultimately, the toolchain should quietly and seamlessly fix all affected applications with the patch but avoid service interruption.

Once the success criteria of the applications are defined by a human DevOps person, then the application configuration and management tools’ job is ensure that criteria is always met. Collectively, this is a new type of packaging that captures the best of all possible worlds, merging configuration and packaging into intelligent application management that can scale and flex as needed.

By capturing the dependencies of configuration and the strictures of traditional packaging, top-down application management methodologies and tools allow a CIO to move an aged C or C++ back-office application into a cloud-native environment just as easily as a passel of Node.js microservices backstopping a mobile application, and have them both run with the same level of continuity and flexibility. Which is really what everyone wants—a safer, easier and better way to run applications without having to worry about the underlying infrastructure.

Conclusion

In a sense, then, the DevOps Revolution is entering a new phase. As microservices continue to slice and dice the old functionality of monolithic apps into numerous smaller apps, the challenge of managing this app proliferation will only grow—and become more complicated.

The way we thought about DevOps tools in the days when cloud computing was relatively young was understandably naïve and not yet informed by the vast application cornucopia we would face in subsequent years magnified by the reality that legacy applications decades old would continue to run in corporate data centers until their code keels over. Now we know and we can design an automation methodology and practices that map to our modern realities. We can do this by giving infrastructure the simple rules and tools it needs, while giving apps more leeway to be themselves and succeed regardless of what is happening at lower levels of the stack.

— Corey Scobie

October 18, 2018
DB-Engines’ Latest Industry Results Reveal InfluxData’s Overwhelming Leadership Position in Rapidly Growing Time Series Database Category
InfluxData Increases Industry Lead with Growing Popularity of 49 Percent; Overall Industry Popularity Nearly 3 Times More than Closest Competitor

SAN FRANCISCO — Oct. 16, 2018 — InfluxData, a modern Open Source Platform built specifically for metrics, events and other time series data that empowers developers to build next-generation monitoring, analytics and IoT applications, today announced its continued position as the overwhelming leader among Time Series Database management systems, according to DB-Engines’ latest results published this month.

According to DB-Engines’ October results, InfluxDB continues its unquestioned lead, outpacing the competition with its popularity increasing 49 percent over the past 12 months and 144 percent over the past two years. InfluxDB is InfluxData’s Time Series Database used as a data store for any use case involving large amounts of time-stamped data – including DevOps monitoring, application metrics, IoT sensor data, and real-time analytics.

The DB-Engines results included rankings of the leading vendors in the Time Series Database category, with InfluxDB’s user popularity ranking nearly 3 times more than the nearest competitor. InfluxDB’s user popularity also scored the biggest increases over the past month and year, as compared to the competitive field.

DB-Engines is an initiative to collect and present information on database management systems (DBMS). DB-Engines also ranked the overall Time Series Database Management System category, which continues to grow in popularity with a 38 percent year-over-year increase, and a 108 percent two-year increase. Overall, InfluxDB continues to show strong popularity among all databases ranked, increasing its ranking to 36 overall, up from 40 a year ago.

“When monitoring how well tools, applications, solutions, and hardware/software are doing, you are always looking at data that is time-stamped, making Time Series databases a fundamental requirement to collect, store and act upon that data as efficiently as possible,” said Mark Herring, InfluxData CMO. “Time Series workloads are unique and are best served by a Time Series database instead of a traditional database. The growth in this database segment is proof that users are finding its capabilities important in collecting and storing data that shows metrics and events for IoT sensors, DevOps monitoring, and real-time analytics.”

Metrics, events, and other time-based data are being generated at an exponential rate, as there is a growing requirement for analyzing today’s complex environments. The InfluxData Platform provides a comprehensive set of tools and services to accumulate metrics and events data, analyze the data, and act on the data via powerful visualizations and notifications. InfluxData’s unique features enable customers to quickly build:
- Monitoring, alerting and notification applications supporting their DevOps initiatives
- IoT applications supporting millions of events per second, providing new business value around predictive maintenance and real-time alerting and control
- Real-time analytics applications that are focused on streaming data and anomaly detection
InfluxData has rapidly built its developer and customer base across industries – including manufacturing, financial services, energy, and telecommunications – by delivering the fastest growing Open Source Platform that enables customers to derive better business insights, data-driven real-time actions, and a consolidated single view of their entire infrastructure – from applications to microservices, and from systems to sensors. More than 420 customers, including Cisco Systems, Coupa Software, IBM, Houghton Mifflin Harcourt, Nordstrom, and Tesla, have selected InfluxData as their modern data platform for metrics and events. InfluxData is pioneering the shift to time series in a modern metrics and events platform, and is making it possible for customers to become data-driven and take on digital transformation initiatives.

About InfluxData

InfluxData, the creator of InfluxDB, delivers a modern Open Source Platform built from the ground up for analyzing metrics and events (time series data) for DevOps and IoT applications. Whether the data comes from humans, sensors, or machines, InfluxData empowers developers to build next-generation monitoring, analytics, and IoT applications faster, easier, and to scale delivering real business value quickly. Based in San Francisco, InfluxData’s more than 420 customers include Cisco, eBay, IBM and Siemens. Visit https://www.influxdata.com/. Twitter: @influxdb.
October 16, 2018
Applitools Delivers Cypress and Storybook SDKs to Provide Developers with Ultra-Fast Visual Validation of Their Web Applications and Components

Automated Visual Testing at the Speed of Unit Testing

SAN MATEO, Calif., October 16, 2018 — Applitools (applitools.com), the leader in Application Visual Management (AVM), today announced expansion of their AI powered visual testing platform to Cypress and Storybook; two popular tools with software developers seeking to build high quality applications faster.

These new Applitools Automated Visual Testing SDKs are engineered to run visual tests instantly as developers write code, enabling them to identify visual bugs as soon as they are introduced. The result is more productive engineering teams, delivering higher-quality apps faster than ever before.

“I love how Applitools Eyes has the smarts to ignore minor visual differences in your components, especially when testing on different browser types where it’s easy for layout to be off by a pixel,” said Kent C. Dodds, JavaScript engineer at PayPal and the creator of TestingJavaScript.com. “I also think is awesome how quickly I can get confidence that my application works across these browsers without actually having to run all my tests in every one of them.”

To get started with Applitools’ new SDKs, sign up for a free Applitools Eyes account at (https://applitools.com/cypress) or (https://applitools.com/storybook).

“Finding and fixing bugs at the application development stage is significantly cheaper and easier than finding and fixing those bugs during QA, or worse, in production,” said Gil Sever, CEO of Applitools. “This dynamic is what’s driving the industry trend of ‘Shift Left’ and embedding testing earlier in the development lifecycle. Increasing release velocity, while maintaining software quality is a huge challenge for R&D teams. By expanding our AI powered visual testing platform to Cypress and Storybook, we provide frontend developers and test automation engineers the tools to do visual testing at the development stage, at the ultra-fast speeds needed to maintain agile and CI-CD development.”

“Our software engineers love the simple configuration, fast performance, and both full page and component-level visual regression testing that Applitools now provides,” said David Corbett, engineering lead at PushPay. “Visual testing is now a vital part of our development routine helping drive faster release cycles with higher quality.”

Applitools Cypress Ultra-Fast SDK empowers developers with an almost instant interactive experience allowing them to see a code’s impact on the UI by headlessly running screenshots in parallel. Also, for the first time, you can use Cypress for visual testing on Firefox, mobile browsers, and Google Chrome.

“Applitools Eyes integrates seamlessly with Cypress and has everything I need for cross-browser visual testing coverage by circumventing the Google Chrome-only restriction built into Cypress,” said Omri Aharon, frontend team leader at Autodesk.

Applitools Storybook SDK visually tests UI web components in parallel, without writing any test code on React, Angular or Vue, enabling ultra-fast codeless validation of massive component libraries in seconds.

“Storybook allows you to visualize your components and all their states, and Applitools allows you to do smart visual-regression testing. Using these tools together provides change detection, which will certainly be of immense value to organizations and individual developers,” said Norbert de Langen, senior front-end consultant at Xebia and maintainer of Storybook.

Join us for a live webinar with frontend developer Gil Tayar entitled “Visual Validation at the Speed of Unit Testing with Cypress and Storybook” at https://goo.gl/vvZdTG

Applitools’ AI powered Application Visual Testing (AVT) technology gives frontend developers, QA analysts, test automation engineers and digital transformation executives the ability to automate the visual testing of web and mobile apps on multiple browsers, devices and screen sizes. By accelerating the testing cycle, companies can improve test coverage and increase the detection of visual bugs dramatically.

Applitools’ Visual AI engine mimics the human eye and brain to avoid undetected bugs and simultaneously minimize false positive bug alerts. The technology can instantly validate entire app pages and their components, and detect layout issues on the most complex and dynamic pages. When development teams are confident that web and mobile applications are rendering properly across all browsers, devices and screen sizes, they are unleashed to push more code more quickly, and with much better quality than ever before.

About Applitools

Applitools is the creator of Application Visual Management (AVM) to help companies release, test and monitor flawless mobile, web, and native apps in a fully automated way. Founded in 2013, Applitools uses sophisticated AI powered image processing technology to ensure that an application appears correctly and functions properly on all mobile devices, browsers, operating systems, and screen sizes. Applitools has customers from a range of verticals, including Fortune 100 companies in software, banking, online retail, insurance, and pharmaceuticals. Applitools is headquartered in San Mateo, California, with an R&D center in Tel Aviv, Israel. For more information, please visit applitools.com.

October 16, 2018
Speed Rules in Chef’s DevOps Survey
DevOps is all about streamlining and accelerating. Organizations that embrace DevOps are driven by a focus on maximizing the combination of efficiency and effectiveness—which explains why speed is the central theme of Chef’s “The State of Enterprise Applications” survey.

Chef surveyed nearly 350 application and operations professionals in an effort to understand trends in DevOps, identify how the industry is shifting and get an idea of what the future of DevOps looks like. What it found is that speed is one of the primary driving factors for organizations that function at the cutting edge of technology. Chef also found that organizations are eager to adopt new platforms that promise to help them move faster.

The Need for Speed

There are a variety of ways to measure success for application development and deployment. You can look at the features and capabilities of the app and whether it delivers the expected functionality, or you can determine success based on user feedback and how satisfied users are with the app experience. According to the Chef survey, 72 percent of organizations are focused on speed as the primary measure of a successful app deployment.

That said, it generally takes weeks—or even months—to get an app developed and deployed. More than 60 percent of survey respondents shared that it takes days or more to complete an application build, and 55 percent indicated that it takes four or more builds before an app is ready to be deployed. Almost 60 percent said it takes days or more to actually deploy the app once the final build is approved.

Platforms and Tools to Accelerate App Deployment

In the quest for speed, organizations are moving to platforms and tools that can help accelerate development and decrease the time it takes to make an app available. According to data from “The State of Enterprise Applications” survey:
- Only 9 percent of organizations are using public cloud for more than 50 percent of app deployments today, but that is expected to increase to 32 percent by 2020.
- There is a 144 percent increase expected in the next two years in the number of organizations using container technology for more than 50 percent of app deployments—to 22 percent from 9 percent today.
- The number of organizations using microservices for more than 50 percent of app deployments is expected to double—to 24 percent from 12 percent—in the next two years.
- More than 80 percent of survey respondents are adopting a multi-cloud strategy.
Putting App Deployment in High Gear

Chef is in the business of automating and streamlining app development and deployment, so it should come as no surprise that the survey included questions related to that as well. The report states, “The most successful software-centric organizations use one consistent way of building, deploying, and managing applications.”

More than 9 out of 10 (93 percent) of survey participants agreed that an application packaging solution that allows deployment to any environment would be valuable. This is especially true when developers have to deal with hybrid or multi-cloud environments.

If speed is your primary measure of success for app deployment, you need to make sure you have the tools and processes necessary to develop and deploy applications as quickly as possible. Chef’s report shows organizations are well on their way.

— Tony Bradley
September 14, 2018