devopsy.kinsta.cloud

Category: Platforms

Why AI Won’t Solve the Hardest Part of Integrations

AI is making it easier for SaaS companies to build integrations. Give a coding agent decent API docs, some context about the systems involved, and a clear prompt, and it can get surprisingly far. It can write the logic faster than most teams could a year or two ago, saving time, reducing repetitive work, and making it easier to respond to customer requests.

Faster creation can make the overall problem look simpler than it really is. The code may come together more quickly, but the operational burden underneath it doesn’t go away.

Building Isn’t the Hard Part

Building the integration itself isn’t the hard part. A good engineer could always get a long way with API docs and some time, and now AI can help do a lot of that faster. The hard part is everything that comes after the code is written.

This is where teams run into unexpected problems. For example, a credential could expire, causing hundreds of synchronization jobs to fail without notice. A change to a third-party API could send back unexpected values, letting bad records slip through unnoticed. A workflow that was quiet all day might suddenly have thousands of events to process at once. Support teams may need to answer a customer asking why an invoice never arrived, but the logs are scattered across different systems, so engineers have to help. This is what integration work looks like when you have more than just a few integrations and customers.

Platform and Infrastructure Are What Makes It All Work

This is why AI doesn’t reduce the importance of integration infrastructure. In many ways, it increases it. If teams can build integrations faster, they’ll build more of them. They’ll promise more integrations, support more workflows, and ship more things that have to run reliably. That puts more pressure on the layer underneath. The question is whether teams have the infrastructure to make integrations work at scale.

Building out integrations to more and more systems with a larger and larger customer base can cause significant operational headaches. At first, developing integrations seems easy. However, as soon as you have to support hundreds or thousands of distinct customers with different configurations, credentials, rate limits, data models, and support expectations, it can become a nightmare. The operational complexity increases rapidly with each integration, including retry behavior, monitoring, tenant isolation, support tools, and security boundaries. Those are the circumstances in which teams realize they were never really building just integrations. They were building an integration platform badly, piece by piece.

Part of the reason this sneaks up on teams is that the early signs of strain rarely look strategic. They look like one-off support tickets, odd edge cases, or temporary patches. A failed sync gets rerun manually. A customer-specific exception gets hard-coded. Another dashboard gets added so someone can keep an eye on it. None of that feels like platform work in the moment. But over time, it turns into exactly that.

For technical leaders, the practical question is where to draw the build-versus-buy line. The cleanest way to think about it is this: Build the parts that are tightly tied to your product’s value, your workflow, and your customer experience. Build where your team’s domain knowledge creates outsized value for your customers, whether that means workflow design, business logic, user-facing configuration, or the parts of the product that make the integration feel native rather than bolted on. Be much more skeptical about building parts that exist solely to keep integrations operational, because those systems usually become more expensive and more brittle as customer count, data volume, and support demands increase.

Ask yourself whether the work your team is doing to develop its own retry systems, auth handling, support dashboards, job runners, or a customer-specific config layer adds value to your product. Or does it simply recreate infrastructure that every software company eventually will need? Some teams will have the scale, constraints, or internal platform maturity to justify owning more of that stack. In those cases, the choice may be reasonable. Most teams, though, should treat that decision as a real trade-off, not a default reflex.

As generating code becomes more cost-effective, that decision becomes more important. When you have an easier way to create integration logic, you tend to underestimate the effort required to run it successfully. AI speeds up building integrations, but it doesn’t remove the operational burden that surfaces later, when the system is live, customers are waiting, and failures are real.

May 28, 2026
Latest Redis Update Streamlines Management of Platform

Redis made a unified release of its namesake data store available today for consistent deployment across all supported platforms. Previously, the pace at which upgrades were made was staggered across different offerings only as they became available.

At the same time, Redis is moving to unify client libraries used to access its open source data store by working directly with the community maintainers of the five most popular client libraries—Jedis (Java), node-redis (NodeJS), redis-py (Python), NRedisStack (.Net), and Go-Redis (Go).

Other capabilities added to version 7.2 of the platform include support for auto-tiering, to more easily migrate less frequently accessed data to less expensive storage devices. This is managed via an enhanced interface for the Redis cluster management and data integration tools, available in preview. Both make it possible to consume data in real-time from another data source, such as a SQL database. Developers can also take advantage of triggers and functions to build those types of applications.

Redis is also previewing a search tool for vector data used to create generative artificial intelligence (AI) applications. Rather than employing a separate vector database to build these applications, the Redis platform supports this data type to enable generative AI applications to run alongside other classes of applications accessing the same data.

Redis CEO Rowan Trollope said collectively these efforts will help DevOps teams reduce costs and streamline the management of upgrades to the platform and updates to applications accessing it.

Most organizations initially adopt Redis to provide a layer of cache using a data store that runs in-memory. However, as more applications are developed many organizations wind up using Redis as their primary database for applications that require a lot of interactivity, noted Trollope.

While developers primarily make that architectural decision, the overall management of the Redis data store falls to DevOps teams that will now find it easier to streamline workflows across multiple instances of Redis running in the cloud, or on a Kubernetes cluster, added Trollope.

Of course, in some cases, organizations still rely on database administrators and data engineers to manage those workflows, but as DevOps continues to evolve, more instances of data stores are being incorporated into workflows managed by a DevOps team. The ultimate goal should be to align DevOps and DataOps best practices to increase the productivity of developers and data science teams building generative AI applications using vector data to customize an existing large language model (LLM).

Regardless of the motivation, what’s clear is the volume of data that needs to run in-memory continues to increase substantially. As that shift continues to occur, more latency-sensitive applications are being deployed. Maintaining the performance of those applications across a highly distributed enterprise environment with multiple service dependencies requires a level of DevOps expertise that is still difficult to find and retain.

August 15, 2023
HashiCorp Advances Open Source Consul Service Mesh

HashiCorp this week updated its Consul service mesh to make it easier to manage namespaces across multiple services.

Previously, DevOps teams would have to manually ensure each namespace assigned to a group of services did not conflict with each other. The release of 1.7 of Consul enables teams to restrict access to services residing in isolated environments on a shared cluster, eliminating the issue.

In addition, DevOps teams can now delegate administrative privileges for a given namespace to individual teams, which enables them to manage their own services in keeping with best DevOps practices, rather than having to rely on a cybersecurity team to manage that process for them.

With the rise of microservices based on containers, interest in service meshes to provide a means to discover and manage services is on the rise. However, services span both emerging microservices-based applications and legacy monolithic applications. Rather than adopting a service mesh that only runs on one platform, HashiCorp is opting for an open source service mesh that spans multiple platforms and is easier to deploy and manage than rival offerings such as Istio.

Amith Nair, vice president of product marketing at HashiCorp, said that approach also makes it easier to deploy a service mesh at scale across multiple clouds and on-premises IT environments. Because Consul is designed to deployed on top of proxy servers such as Envoy or NGNIX, it can be deployed almost anywhere to manage services sprawl across the extended enterprise, noted Nair.

As far as the adoption of service meshes are concerned, it is still early days. Many organizations are in the process of shifting away from managing applications to focusing on services that span multiple applications. Given all the dependencies that exist between various services, that shift represents a major challenge. A service mesh alleviates some of that challenge by providing a mechanism for both discovering and governing services that are increasingly interdependent.

That approach also provides the added benefit of allowing teams tasked with governing and auditing IT environments to focus more on higher levels of abstractions versus updates to every line of code on which those services are constructed.

For now, there are no standards, de facto or otherwise, in terms of service meshes. Many organizations may find themselves adopting multiple frameworks, which may lead to further advances in interoperability specifications such as the Service Mesh Interface between rival platforms.

Less clear for now is who inside an IT organization will be responsible for acquiring and managing a service mesh. In some organizations it might be a network operations or cybersecurity team. In other organizations, those roles may have already been incorporated within a larger DevOps team.

Regardless of the approach, the need for some type of service mesh is becoming more apparent. The good news is there is now no shortage of options. However, DevOps teams should note that in terms of overall complexity and amount of compute resources consumed, not all services meshes are the same.

— Mike Vizard

December 11, 2019
Netifi Rises to Microservices Integration Challenge

Netifi this week launched an integration platform based on the open source RSocket communications protocol to replace HTTP ad REST application programming interfaces (APIs) as the mechanism for connecting microservices. RSocket was originally created by Netflix and is now being strengthened via contributions from Netifi, Facebook and Pivotal Software for use within enterprise IT organizations.

Fresh off raising $2 million in seed funding, Netifi is also committing to support a community edition of RSocket later this year.

Company CEO Robert Roeser said the Netifi platform is designed to make it easier to build microservices and interconnect them. Most of those microservices are being built using Docker containers, but Roeser said that, as part of a polyglot approach to integration, Netifi is leveraging RSocket to connect microservices built using a variety of runtimes as well as provide access to legacy monolithic applications. The Netifi platform can be deployed on-premises, in a public cloud or in a hybrid fashion.

Roeser said RSocket was born of necessity at Netflix because the number of microservices that needed to be interconnected at scale was simply too complex a task using HTTP and REST APIs. Soon after, Facebook also started employing RSocket and now Netifi and Pivotal are making contributions designed to make Rocket more accessible for traditional enterprise developers. In the case of Netifi, that means providing mechanisms to both discover and advertise microservices and provide a layer of abstraction that shields developers from the underlying complexity of the network underlay, he said.

As applications based on microservices become more widely distributed, enterprise organizations tend to become more intimidated by the challenges associated with managing them at scale. Traditional enterprise IT organizations don’t have access to a small army of software engineers to solve the problem. As a result, many of them retreat to building monolithic applications in which all the services that need to be accessed are baked into the application itself. They typically sacrifice scale and flexibility in favor of a construct that is both familiar and easier for them to navigate, Roeser said.

The challenge Netifi and other supporters of RSocket will face is the considerable amount of inertia surrounding REST APIs and HTTP. Several generations of developers now consider REST APIs to be the default mechanism for connecting various applications together. The issue many of them will need to wrestle with is the extent to which the rise of microservices breaks that integration construct. A shift away from REST APIs also could have significant implications regarding how services are exposed externally, how pipelines are constructed within DevOps environments and other factors.

It remains to be seen whether integration platforms based on RSocket or some other approach ultimately makes microservices more accessible to enterprise IT organizations. But significant resources now are being poured in to solve the problem, many of which leverage contributions of companies, such as Netflix and Facebook, that already rely on thousands of microservices to deliver a broad range of cloud-native applications.

— Mike Vizard

August 17, 2018
How to build 12-factor microservices applications on AWS with Containers
If you are developing software in 2017, chances are you are looking at microservices-based architectures. Microservices is an approach to application development in which a large application is built as a suite of modular services. Containers are a natural fit because of the isolation and packaging they provide. Containers further enable speed, resource density, flexibility and portability.

To get the benefits of containers and microservices, look to a methodology known as the 12-factor app, a popular methodology for building “software-as-a-service apps that:
- Use declarative formats for setup automation;
- Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
- Are suitable for deployment on modern cloud platforms;
- Minimize divergence between development and production, enabling continuous deployment for maximum agility;
- And can scale up without significant changes to tooling, architecture, or development practices.”
In this article, we will highlight implementing the paradigms stated for deploying application in containers using AWS primitives.

Developing Microservices

An effective way to achieve a clean contract in the system is by defining the boundaries for services is specific to your application’s design. The microservices define a clean contract in the application layer. The microservice can be tracked in a version control system such as Git or AWS CodeCommit, a fully managed source control service that makes it easy for companies to host secure and highly scalable private Git repositories, as an alternative to GitHub.

Isolation of crashes, isolation for security and independent scaling all need to be considered. Containers wrap application code in a unit of deployment that captures a snapshot of the code as well as its dependencies, thus extending portability. Microservices architecture inherently grant that if one micro piece of your service is crashing, only that part of your service will go down.

Docker provides the packaging of operating system, application and dependencies thus enabling portability. Running many Docker containers at scale is a hard problem of the order of O(n²). Amazon EC2 Container Service (ECS) is a highly scalable, high-performance container management service that supports Docker containers and enables Docker-based applications on a managed cluster of Amazon EC2 instances. Amazon ECS eliminates the need to install, operate and scale cluster management infrastructure, enabling a highly concurrent environment.

There are multiple container orchestration platforms that do a good job of running containers at scale, but managing them on the platform itself is a challenge. This requires the user to spend considerable time on operating the platform instead of focusing on the application.

While Docker enables clean packaging of software, the application should be written to be consistent across environments; environment dependencies should be removed from the code to enhance disposability.

Parameter Store, a feature of Amazon EC2 Systems Manager, provides a centralized, encrypted store for sensitive information such as secrets and configuration. The service is fully managed, highly available and highly secure. Parameter Store is accessible using the Systems Manager API, AWS CLI and AWS SDKs. Secrets can be easily rotated and revoked. Parameter Store is integrated with AWS KMS so specific parameters can be encrypted at rest with the default or custom KMS key. Importing KMS keys enables you to use your own keys to encrypt sensitive data.

Figure 1: Storing Container Secrets in parameter store

Access to Parameter Store can be controlled by IAM policies and supports resource level permissions for access. An IAM policy that grants permissions to specific parameters or a namespace can be used to limit access to these parameters. CloudTrail logs, if enabled for the service, record any attempt to access a parameter. Containers deployed on Amazon EC2 Container Service (ECS), which provides orchestration for your containers, can access these secrets from the parameter store.

Amazon EC2 Container Service allows you to lock down access to AWS resources by giving each service its own IAM role.

Scalability

An ECS service can be configured to use service autoscaling to adjust its desired count up or down in response to CloudWatch alarms. Autoscaling gives an effective usage of the compute resources. Amazon ECS publishes CloudWatch metrics with the service’s average CPU and memory usage. These service utilization metrics can be used to scale the service up to deal with high demand at peak times and to scale the service down to reduce costs during periods of low utilization.

As services scale and run multiple applications on an ECS cluster, dynamic port-mapping becomes essential. Application Load Balancer offers a high-performance load balancing option that operates at the application layer and allows to define routing rules based on content. With Application Load Balancer, you can specify a dynamic host port to give your container an unused port when it is scheduled on an EC2 instance. The ECS scheduler will automatically add the task to the Application Load Balancer using this port.

Using AWS CloudFormation gives developers and systems administrators an easy way to create and manage a collection of related AWS resources such as Application Load Balancer, ECS Clusters, VPC, service definitions and task definitions.

As described above, using a secret management store such as the Parameter Store allows for the application to be executed in the execution environment as one or more processes. The services are stateless, share nothing and rely on a stateful backing service to persist data.

The services can rely on backing services such as data stores (Amazon RDS, DynamoDB, S3, EFS and RedShift), messaging/queueing system (SNS/SQS, Kinesis), SMTP services (SES) and caching systems (Elasticache). The code for a 12-factor app makes no distinction between local and third-party services.

Fig 2: An example microservices deployment on AWS.

Continuous Deployment

Delivering new iterations of software at a high velocity is a competitive advantage in today’s business environment. The speed at which organizations can deliver innovations to customers and adapt to changing markets is increasingly a pivotal attribute that can make the difference between success and failure.

Continuous deployment enables developers to ship features and fixes through an entirely automated software release process. Instead of batching up large releases over a period of weeks or months and conducting deployments manually, developers can use automation to deliver versions of their applications many times a day as new software revisions are ready for users. In the same way cloud computing abbreviates the delivery time of resources, continuous deployment reduces the release cycle of new software to your users from weeks or months to minutes. Various techniques such as rolling updates, blue-green and canary deployments can be used to enable a continuous delivery pipeline.

Updating a service in Amazon ECS is enabled at the scheduler level. A running service can be updated to change the number of tasks that are maintained by a service or which task definition is used by the tasks. When the service scheduler replaces a task during an update, if a load balancer is used by the service, the service first removes the task from the load balancer and waits for the connections to drain. AWS provides AWS CodeCommit, CodePipeline and CodeBuild to enable an efficient continuous delivery pipeline. The below reference architecture illustrates such a pipeline.

Fig 3: Continuous Delivery and Deployment

In the above reference architecture, the developer commits code into a CodeCommit, which triggers a CodePipeline. The CodePipeline branches into provisioning the infrastructure using AWS CloudFormation and builds a Docker image using CodeBuild. CodeBuild builds the Docker image and pushes it to ECR, while CloudFormation has deployed the ECS cluster. The ECS service, which is in autoscaling mode, picks the image and deploys. The same workflow works for updates, with the added step of an update stack. With update stack, the delta change is understood by CloudFormation and the update service replaces the containers with the new image.

Blue/green deployments are a type of immutable deployment that help you deploy software updates with less risk. The risk is reduced by creating separate environments for the current running or “blue” version of your application, and the new or “green” version of your application. This type of deployment gives you an opportunity to test features in the green environment without impacting the current running version of your application. When you’re satisfied that the green version is working properly, you can gradually reroute the traffic from the old blue environment to the new green environment by modifying DNS. By following this method, you can update and roll back features with near zero downtime.

Fig 4. Implementing Blue Green with ECS

As demonstrated in the above reference architecture, a target group and path-based routing at the application load balancer could be used to direct traffic from the ALB to a blue (live) service and a green (test) service. Once the testing is completed, the target groups could be switched to redirect all live traffic to the green (live) service and all internal traffic to blue (deprecated) service.

Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.

Fig 5. Implementing Canary deployment for Containers on AWS

In the above reference architecture, a container can emit CloudWatch events that can be used to determine whether to increase the flow of traffic. When a container specifies it can take more traffic, the Amazon R53 weighted routing can increase the traffic to the application load balancer and thus to the container. As canaries proliferate, maintaining the state of each canary is important for rollback and deployment. DynamoDB and a lambda filter allows the state to be stored in the pipeline based on CloudWatch events. AWS Step Function helps coordinate the components of the pipeline using visual workflows.

Another consideration is that the development, staging and productions system should be as similar as possible. By setting up an efficient deployment pipeline this can be achieved. The environment from an operational and a development perspective should be closely aligned in terms of the operating system, Docker version, shared libraries and microservices deployed.

Developers can also run one-off admin processes as a task, in an identical environment as the regular long-running processes of the app. They run against a release, using the same codebase and configuration as any process run against that release. Admin code can be shipped with application code to avoid synchronization issues.

Monitoring and Governance

Application logs are useful for many reasons. They are the primary source of troubleshooting information. In the field of security, they are essential to forensics. Web server logs are often leveraged for analysis (at scale) to gain insight into usage, audience and trends. A 12-factor app never concerns itself with routing or storage of its output stream. Streaming logs collected from the output streams of all running processes and backing services to centralized logging such as AWS CloudWatch. Amazon ECS provides a logdriver on the task definition that ships streams logs to CloudWatch.

Centralized logging has several benefits: Amazon EC2 instance’s disk space isn’t being consumed by logs and log services often include additional capabilities that are useful for operations. For example, CloudWatch Logs includes the ability to create metrics filters that can alarm when there are too many errors and integrates with Amazon Elasticsearch Service and Kibana to enable you to perform powerful queries and analysis.

While debugging issues, tracing and troubleshooting is an important aspect. The AWS X-Ray daemon is a software application that gathers raw segment data and relays it to the AWS X-Ray API. The daemon works in conjunction with the AWS X-Ray SDKs and must be running so that data sent by the SDKs can reach the X-Ray service. You can easily run AWS X-Ray as a daemon on a ECS cluster to enable tracing of the containers.

Governance is a key aspect of software design and development. Maintaining a consistent style and standard along with operation SLA is paramount to enterprise deployments. SLAs around security, recovery time objective and recovery point objective must be considered. AWS Service Catalog could be used for listing microservices stacks in a catalog, with access control and notifications mechanism.

Conclusion

With AWS primitives, you can utilize the 12-factor app pattern to achieve scalable, fault-tolerant and highly available microservices with continuous deployment. You can find further resources at: https://aws.amazon.com/ecs/getting-started/ and https://aws.amazon.com/ecs/resources/

Arun Gupta is a Principal Open Source Technologist at Amazon Web Services. He has built and led developer communities for 12+ years at Sun, Oracle, Red Hat and Couchbase. He has deep expertise in leading cross-functional teams to develop and execute strategy, planning and execution of content, marketing campaigns, and programs. Prior to that he led engineering teams at Sun and is a founding member of the Java EE team. He has extensive speaking experience in more than 40 countries on myriad topics and is a JavaOne Rock Star for four years in a row. Gupta also founded the Devoxx4Kids chapter in the US and continues to promote technology education among children. A prolific blogger, author of several books, an avid runner, a globe trotter, a Docker Captain, a Java Champion, a JUG leader, NetBeans Dream Team member.

Asif Khan is a Tech leader with Amazon Web Services. He provides technical guidance, design advice and thought leadership to some of the largest and successful AWS customers and partners on the planet. His deepest expertise spans application architecture, containers, devops, security, machine learning and SaaS business applications. Over the last 12 years, he’s brought an intense customer focus to challenging and deeply technical roles in multiple industries. He has a number of patents and has successfully led product development, architecture and customer engagements.

— Asif Khan
October 15, 2017
How to Handle DevOps Microservices (Hint: Carefully)
Given the dizzying amount of best-of-breed tools that can be involved in the development pipeline, a well-written microservice comes to the rescue with just enough code to keep things running. But too much of anything is never good. Here’s how and when to use microservices.

Microservices are all the rage right now: these mini-apps are being used to integrate distributed applications that can be modified more easily. Microservices act like the glue, holding together processes and systems in the DevOps automation workflows. This means faster, more automated cycles, better implementation of continuous delivery and increased visibility into DevOps processes and deployments.

For developers and testers, who generally love the best-of-breed approach of using whatever tool they prefer for the job, microservices allow them to do that by affordably connecting many different open-source and commercial tools in the DevOps pipeline. While some of these tools have built-in integrations to other popular tools, those integrations may not be exactly customized for your needs. Asking the vendor to build custom integrations for you can be cost prohibitive and may not be feasible within the time frame your organization is looking to implement.

So with microservices, development teams have the flexibility to build their own tool stack and integrate everything to achieve full visibility into the development process. Equally helpful, REST APIs are super easy to work with compared with legacy APIs; developers can handle writing microservices without specialized expertise in the products that are being integrated. These are just a few of the extremely powerful advantages of the microservices approach.

Yet as with every other cool technology, there are a few hitches, as follows:
1. Hard to handle. Microservices depend upon vendor APIs, and when those change, the service will break. Then, you’ve got to rebuild the service from scratch. That is a time-consuming task that detracts from the main job at hand: writing and refining code. In an environment with hundreds of microservices, pretty soon, you’ve got developers spending the bulk of their time updating those pesky mini-apps in your devops pipeline instead of building new user features. Costs escalate and timelines slip.
2. Slapdash processes. Let’s face it, when you’re writing a microservice just for your team, you’re going to do it as quickly as possible, thereby skipping a few steps that can make the microservice less fragile. A vendor, meanwhile, writes a micro-service to help hundreds of customers – therefore, it’s got to be bulletproof. The internal approach for integration through microservices can be more prone to breakage. Once one service breaks, there is the inevitable domino effect with other integration points, meaning down time in your development process.
So, now what? It’s possible to make all this a bit easier. First, make sure that you’ve got the economics straight. Will developing microservices as your integration strategy be cheaper (factoring in staff time) than having vendors do it for you? If cost is not the main consideration, do the benefits of having a custom-built DevOps tool stack outweigh the complexity issues including downtime risks when a service breaks? Is there a clear-cut benefit from having a custom integration over taking the vendor’s not-quite-perfect integration? Do the analysis before choosing the microservices path – and remember to tie all this back to business benefits.

Here are some ways to reduce the complexity of microservices:

Go hybrid: In most cases, organizations will find that using a combination of vendor integrations and microservices is often the answer.

Outsource: For business-critical applications, it’s not a bad idea to let an outside development firm handle the microservices portion for you. That will reduce your risk and free up your developers to focus on building products not managing integrations.

Tools and languages: Choose languages for writing microservices that work well with REST APIs, such as Python and Ruby. As well, keep an eye out for tools that can help when you’re doing this in-house, such as Zapier or TaskTop. We expect those automated options to only grow, as companies expand their use of microservices and containers to optimize their DevOps operations.

About the Author/Kevin Dunne

Kevin Dunne is the vice president of strategy and business development at QASymphony. He has a deep interest in the emerging trends in software development and testing. Kevin joined QASymphony from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. He can be found online at LinkedIn and Twitter.
November 2, 2015
DevOps Leadership Series: Monitoring Containers and Microservices

Trevor Parsons (@trevparsons) is a Co-Founder and Chief Scientist at Logentries, a leading SaaS-delivered log management and analytics service. I caught up with Trevor at the Velocity Conference in Santa Clara and asked him what themes were resonating with attendees this year.

For this episode of the DevOps Leadership Series, Trevor briefly illustrates some current problems with state of microservices and container-based architectures, while sharing a positive outlook for the future.

https://www.youtube.com/watch?v=zHRE4011WVk

Trevor says there’s been a lot of development in how to log and monitor containerized systems and he sees better support from Docker for logging, showing an increasing focus on this topic in 2015 and beyond. He anticipates the next year to have huge improvements in managing and monitoring these new systems and architectures.

Next up in the DevOps Leadership Series, I headed to London for the DevOps Connect: Rugged DevOps event, where we’ll discuss more about Rugged DevOps practices. In London, I was able to catch up with Helen Beal (Ranger4), Justin Arbuckle (Chef), and Gareth Rushgrove (Puppet Labs).

If you have missed any of the other videos from this series, you can find them here. (We’re up to 15 so far).

June 11, 2015