devopsy.kinsta.cloud

Tag: microservices

DevOps: Time for Developers to Dig In
Speaking to developers and project managers at the Gartner Catalyst Show, Jenkins World and Atlassian Summit revealed some insights about how most IT specialist perceive DevOps. Yes, I had a busy end of summer schedule attending events and talking to a wide range of developers and project managers about DevOps.

two dogs digging together in one hole in the ground

What I learned is that most people have not yet figured out what is meant by DevOps. What most people told me is that they are doing DevOps explaining they have a CI/CD pipeline. When questioned further about how they perceived DevOps, they believed DevOps was about creating a CI workflow that developers and sometime-testing teams could execute to automate builds, deploys and testing. One of the most ironic of these conversations was project managers making the claim that their CI server performed builds and deploys.

Well folks, DevOps is not about a CI/CD pipeline. And contrary to popular beliefs, your CI server does not perform builds and deploys any more than it performs automated testing. Your CI/CD pipeline orchestrates build and deploy processes in the same way that it executes an external tool for test automation. The ugly truth is that your CI/CD pipeline is executing one-off build and deploy scripts, the same scripts used in your waterfall practice, but just triggered by your CI/CD process. These scripts cannot easily adapt across the continuous delivery pipeline. Testing and production environments are configured differently. The build and deploy scripts must be tweaked, maintained and debugged in the same way they were during waterfall practices. Once ready, they are then called by your CI/CD workflows. DevOps is different.

DevOps demands that your developers and operation teams share and collaborate from the earliest phases of a project. In essence, this requires that more of the operational duties be shifted left and directly onto the shoulders of developers. This is precisely were the responsibility and control should be. Operation teams need knowledge and transparency so they can communicate infrastructure requirements early and often to the developers. Eventually what we will see is a decline in the number of operational resources. A “release engineer” who managed production deployments said, “If we define our DevOps process correctly, my job will not exist in the future. Instead, automation will replace the manual Ops scripts, allowing Dev teams to do 70 percent of my work.” And that, my friend, is real DevOps.

Developers, Dig In

So it is time for developers to really dig in to DevOps. What I mean is developers must begin walking away from automating most of the processes by a one-off script and begin incorporating tools that perform DevOps tasks from continuous deployment, security scanning and performance monitoring. And different platforms need different tools. Project teams will need the power to select the tools that work for them. The days of “legacy” purchases of a single tool for the enterprise is long gone. High-dollar operational tools are high-risk and incur technical debt when developers choose to use a different solution. DevOps means giving development teams more control and purchasing authority for automation tools that can be managed at a project level, not an enterprise level. These tools must support a process where the developers work on the declarations followed by testing and production consuming the process with a good amount of transparency. Scripts cannot achieve this, even when triggered by CI.

Our future is becoming more and more complex. Most companies I spoke to still managed over 70 percent of monolithic applications. The writing on the wall is in the 30 percent. With microservices and containers, operational tasks are going to become more complex, not less. The sooner developers can become the core owners of operational tasks, the easier it will be to adopt a microservices architecture. Managing microservices will not be the job for the operations team. It will need to be done by the developers who have the intimate knowledge of their application.

To mature from CI/CD to DevOps is going to require a close look at the engine under your CI/CD hood. When developers and project managers begin to really dig in and see how the engine is running, it will be clear that achieving DevOps is a bit down the road. And there is urgency in this process. Leaner and better ways of writing and releasing code is upon us. Most of us are just not ready to toss out some of the old habits from waterfall practices to get there.

Some departing thoughts:
- Acknowledge that CI/CD is a good place to be, it is just not DevOps.
- Look carefully at your underlying processes that are called by CI/CD. How well do they support your production environment?
- Can your CI/CD workflow at Dev support a production deploy? If not take the time to understand why.
- Are your developers working late to get a code update to production?
- Do you have a clear continuous feedback loop that shows where a code update is running, and on what exact endpoints?
- Do your developers know what infrastructure updates are going on in production today?
- How do your developers communicate infrastructure updates to production teams? Can they do it alone?
The time is now for self-examination and a clear honest appraisal of just how automated your core operational tasks are. If they are built upon one-off scripts, you should assume you have some work ahead to really begin moving to a DevOps practice that can be declared by developers, consumed by all runtime environments and is transparent to all.

And remember, microservices are chasing you.

About the Author / Tracy Ragan

Tracy Ragan is COO and Co-Founder, DeployHub. She has extensive experience in the development and implementation of business applications. It was during her consulting experiences that Ms. Ragan recognized the lack of build and release management procedures for the distributed platform that had long been considered standard on the mainframe and UNIX. In the four years leading to the creation of OpenMake Software she worked with development teams in implementing a team-centric standardized build to release process. Connect with her on LinkedIn.
September 25, 2017
New Relic Tracing Software Pinpoints Source of IT Issues

At a FutureStack 2017 conference this week, New Relic previewed an implementation of distributed tracing software that has the potential to close the war rooms where IT operations assign blame for application failure.

New Relic CEO Lew Cirne says a Distributed Tracing capability that New Relic previewed this week will enable developers or IT operations teams to pinpoint the precise source of any given performance issue. Rather than wasting hours on root cause analysis, Cirne says DevOps teams will now be armed with dashboard they can navigate to visually inspect what elements of a distributed computing environment are specifically affecting their applications.

Based on the open-source Open Tracing software being advanced by the Cloud Native Computing Foundation (CNCF), Cirne says New Relic opted to embrace an open initiative that should lead to more actionable intelligence being derived from the data New Relic collects.

At this juncture, Cirne contends that deploying an application in production that has not been instrumented borders on the criminal. He concedes, however, the preponderance of applications deployed in production environments today are not instrumented largely because the total cost of instrumenting legacy applications has been cost-prohibitive. But as IT monitoring software becomes less expensive to invoke using agents that communicate back to a software-as-a-service (SaaS) application, most new applications being deployed in the cloud are now being instrumented.

To help further that goal, New Relic this week also announced support for .Net Core 2.0 framework recently made available on Microsoft Azure and added support for six additional Amazon Web Services (AWS) services. New Relic now supports a total of 25 AWS services.

At the conference Cirne also showed how IT organizations can now invoke New Relic application programming interfaces (APIs) to spin up a dashboard to track specific events associated with, for example, the rollout of a new application.

Access to the data New Relic surfaces, notes Cirne, in turn helps fuel adoption of DevOps because organizations gain confidence in their ability to more rapidly build and deploy applications. That confidence will only increase as IT organizations avail themselves of artificial intelligence (AI) software in the form of machine learning and, soon, deep learning algorithms to make more reliable decisions based on patterns in their IT environments. New Relic, he adds, is able to fuel those algorithms because the service collects 1.5 billion metrics and events every minute. That said, humans will still be required to manage the overall IT environment.

Cirne maintains that the best way to collect all that data is to employ agents, noting New Relic is adopting those agents to make them lightweight enough to even deploy on microservices based on containers.

New Relic naturally is not the only provider of IT monitoring tools investing heavily in advanced algorithms. In the not-too-distant future, it’s probable that algorithms deployed by different vendors will share insights with one another. In the meantime, IT administrators can take some comfort in the fact that it should soon become easier to manage IT at scale.

— Mike Vizard

September 14, 2017
SecOps: The Next Stride for DevOps
Global IT spending is now touching a figure of $4 trillion. In today’s technology-intensive environment, data is the biggest commodity, more valuable and powerful than ever. And like Peter Parker’s uncle Ben noted, “With great power comes great responsibility.”

Security has always been a big concern for valuable things and IT is no exception. IT as a whole is trying to push security left in the development cycle—trying to involve it in every step of the development cycle. And just when development and operations teams are getting used to the “esprit de corps” we call DevOps, I think it’s time we add the third musketeer: security.

What is SecOps?

SecOps is a collaboration between security and operations teams, just like development and operations teams collaborate on DevOps front. SecOps is a set of practices organizations need to follow, processes they need to execute and tools they need to use to ensure the security of their application environment. SecOps is making sure organizations do not sacrifice security to attain set performance and uptime indexes.

In a typical development cycle—requirements gathering, design, development, testing, implementation or deployment and maintenance—security normally is introduced in the later stages, somewhere between testing and deployment or even later. But SecOps is all about making sure to introduce aspects around security much earlier or at each stage of the software development life cycle (SDLC).

I know what you are thinking: This is going to complicate things and increase the time to delivery. This is where operations and development teams need to join forces to uncomplicate the things and make it time efficient practice. Next thing you must be thinking of is, Why so much hassle? Think of it the other way. Wouldn’t it save more time when you address the security concerns at much earlier stages than at the time of delivery or implementation? All it takes is an amalgamation of the security group, development team and operations team; a little bit of planning; and a whole lot of execution.

SecOps + Containers

Containerization is slowly but steadily moving from an alternative to full virtualization to a serious platform for running your applications. Containers have some obvious advantages including scalability and flexibility, and this solves most of the problems related to resources in case of application development. Reduced size; reduced time to provision application environment and testing; platforms including Docker, Solaris Zones, BSD Jails; and orchestration platforms including Kubernetes, CoreOS Fleet, Amazon ECS and OpenShift make containers a more preferred option for application development environments.

This increased traction toward containerization points to the increased need to concentrate on security aspects. Here are some best SecOps practices for container environment you and your organizational teams can follow:
- Authentic sources and images: Always check for authenticity of container images. There are various tools such as Docker’s security scan. With Docker Cloud and Docker Hub you can scan images to check for potential security vulnerabilities. Most images are built from some base image and not built from scratch, so there is always a threat with the used images.
- Vulnerability management tool: There are tools available in the market to analyze container image formats and libraries for threats before you actually start using them.
- Follow benchmarks and hardening guidelines: Always make sure you do the checks and follow hardening guidelines for containers, images, hosts and platforms before you start with production. There are few standards and benchmark checks for containers such as CIS’s Docker security benchmark, PCI compliance checklist, etc.
- Periodic auditing: Regular auditing of your application environment can help you save yourself from the future troubles. Moreover, automation of auditing process can help in detection of unused images and containers.
- Use of management frameworks: Use frameworks that can automate behavior profiling and control all the users, authorize the access to the containers, images and hosts.
- Security built in to container engine systems and third-party security solutions: Third-party vendors have a number of applications for container security in addition to security systems of container management platforms.
Dev + Sec + Ops

With the continuously increasing business demands for new applications and software, and new practices and development trends such as DevOps, Agile, cloud, automation, CI/CD and others, traditional security needs to upgraded in the new paradigm. Thankfully, some of these practices facilitate the security. Consider CI/CD as an example: Continuous integration requires continuous integration tools, or what we call build servers. Some popular examples are Jenkins, TeamCity, GitLab CI, Travis CI, Bamboo, Go CD, CircleCI and Codeship. The best SecOps practice is to check and fix vulnerabilities at early stages as a part of CI/CD workflow. Integration between authentication, scanning, management tools and CI/CD pipeline tools could be the best possible solution to your security-related problems. Some easy-to-implement solutions can include automated security testing, static code analysis, authentication checks and login tracking.

SecOps enable organizations in lifecycle management, analysis of security threats, incident management, optimizing and measuring the effectiveness of security controls, reduced breach response time, reduced security risks and increased business security. The basic principle on which SecOps works is Avoid, Analyze, Respond, Review, Repeat. By analyzing the security events and data, you can build incident response plans to avoid future unwanted events.

Frameworks and Tools

Now that you have a clear understanding of why you need your security, development and operations teams to work together, let’s see what tools and frameworks you can use.
- Docker-native tools: If you are using Docker as a platform then you can use few security tools provided by Docker itself for the security of production environment: Docker Bench and Docker Notary. Docker Bench is a script that checks common best practices around deploying Docker containers in production. Docker Notary enables you to check whether content is from a trusted publisher.
- Chef: Chef provides different tools including Inspec to automate security testing.
- Puppet: Puppet provides security compliance and policy defining frameworks.
- Ansible: Ansible provides system tracking, setting up firewall rules, user lockdown and compliance automation solutions.
- CoreOS Clair: CoreOS Clair is an open-source project for vulnerability analysis in applications and Docker containers.
- SaltStack: SaltStack can help in orchestration and automation of security practices solutions for containers.
This is just a look at some of the most popular ones. If you want, there are a number of others that can look after the security of your application environment.

The main motive behind implying SecOps practices in any organization is involving security team at all possible stages to remove any ambiguity in any stage of development rather than security team providing analysis reports to the operations team and then sitting back and enjoying the show. When these teams perform in a synergistic manner, the business focus can be shifted to other important things.

About the Author / Chaitanya Jawale

Chaitanya Jawale is founder and CEO of Opcito Technologies, a leader in microservice-based product engineering and automation. Chaitanya comes with strong background in product engineering, data center automation, DevOps and multi-cloud orchestration and management.
August 14, 2017
Sprinting in a DevOps Marathon: Tips for Success
Remember the good old days of 2007, when Heroku was the shiny toy everyone wanted? Thanks to Moore’s law and the evolution of tech, 2007 seems like a lifetime ago. In fact, 2015 seems like a lifetime ago, now that machine learning has advanced for artificial intelligence to “wake up”—but I digress.

DevOps and building applications in a microservice architecture appears to be here to stay. Monolithic applications have been around since the advent of the “stack,” but thanks to DevOps, we can build faster and smarter with better quality and lower cost. Consequently, it’s dumbfounding why only .5 percent of engineers operate DevOps (according to Gene Kim). DevOps would unlock trillions of dollars if the other 99.5 percent made this adoption, thereby ushering in a new era of economic prosperity.

If you’re part of the other 99.5 percent, let’s go through the considerations for DevOps adoption—it’s the wave of the future, so you better start now!

The Road to DevOps Success

Assess the competency and maturity of development practices and processes of your organization across the following parameters:
- Culture (i.e. collaboration and standardization)
- Design and architecture
- Data analysis and management
- Build, continuous integration and continuous deployment
- Assessment and testing
- Application deployment across environments (Dev, Test, Production)
- Continuous delivery and application upgrades/updates
Assessing the aforementioned practices and processes result in a baseline to compare against industry standards (see Puppet’s “2017 State of DevOps Report“) and identify areas of improvement. This may seem intuitive or obvious, but true agility through DevOps requires frequent evaluations as new tools, practices and methodologies become available (i.e., you’re not still using dial up now are you?).

Enhance and Improve the Culture with Shared Values and Objectives

Design, Dev, Operations, QA, Product and other applicable teams historically have operated independently of one another in “silos,” which is the antithesis of DevOps. The goal need not be pushing code, configuring applications or testing; the goal should be to deliver value to the customer. Unfortunately, the culture of most organizations inhibit teams from maximizing value because they’re removed from the customer and seldom listen to the sales team (which I emphatically state as a seasoned sales professional!).

That said, this is the easiest thing to fix by implementing the following steps:
- Introduce a feedback loop including customers, sales, marketing and customer support to introduce new ideas to product so value is maximized.
- Clearly articulate goals to motivate product teams and get them excited about their work.
- Institute a culture of continuous improvement by listening to developers, operations, design, product, etc.
Base Decisions on Facts, not Conjecture

Seldom do organizations correlate sales and customer satisfaction metrics with product investment and product operations. All too often, organizations let sales or product dictate the best direction for the company when they need to be evaluated in conjunction due to their impact on profitability (i.e., building products to drive sales or letting sales dictate what products to build). DevOps expedites the delivery of products, thereby aligning the objectives of product with the goals of the sales team. This enhanced agility makes it’s easier to incorporate feedback from sales to enhance products while enhancing sales by delivering value faster, lowering the sales cycle and fostering happier customers!

Choose the Right Tools, not the Popular Ones

Months ago, the Bluemeric team started an engagement with a Fortune 500 team that was beginning its journey into containers. Long story short, this client evaluated the container platforms based on name recognition, not on the relative strengths and weaknesses or how the PaaS will achieve the client’s goals with the least amount of effort. The client reviewed dozens of platforms and entertained 10 for a proof of concept, but only one (and a relatively unknown PaaS) was able to install on its infrastructure (AWS, Azure and Google), spin up a cluster, build the application and deploy the applications. The competitors had tens if not hundreds of millions of dollars in revenue and thousands of customers, but the one that got the job done wasn’t the first, second or even third choice. It was the lightweight PaaS that Bluemeric recommended, which promised simplicity, minimal effort and ease of use that doesn’t drown customers with unnecessary features—and which actually worked. Obviously, this isn’t limited to PaaS; it’s an example on why decisions to adopt tools, methodologies or vendors must have a thoughtful evaluation, free from outside opinions and bias.

That being said, implementing and adopting DevOps is neither easy nor fast, but it will be a requirement for all businesses in the very near future. As noted earlier, Gene Kim discovered that .5 percent of all software engineers currently operate in a DevOps environment, which is astonishing when comparing profitability against those who aren’t practicing DevOps. Once the trend becomes mainstream in the world of finance, the other 99.5 percent of software engineers better catch up or face the consequences.

— Gabriel Deupree
July 12, 2017
Q&A: Michael Beckley, CTO/CCO, Appian

Recently I had the chance to speak with Michael Beckley, chief technical officer and chief customer officer at Appian, about his company’s move to go public and the DevOps space in general. For those of you who don’t know Michael, he is a founder of Appian and leads the company’s technology vision and oversees customer initiatives worldwide. He also serves on the Industrial Advisory Board for the University of Virginia’s Computer Science Department and is a member of the University of Maryland Advisory Board in Computing. He has an interesting take on the IT space and DevOps in particular. Read on for our discussion.

Alan Shimel: Michael, what do you think has been the “special sauce” that has led to Appian’s success to date?

Michael Beckley: With Appian, companies build unique business applications up to 20x faster and mobile-enable and modernize existing systems. For example, a company like Ryder was able to build a web and native Android tablet application that cut the time it took to rent a truck in half.

But the “special sauce”? That’s Appian’s culture of innovation. Our engineers think long-term and invest in breakthrough tech like our patented SAIL UI technology for zero code native mobile apps. Thanks to SAIL, the web apps you configure in Appian automatically deploy to iOS and Android as native, full-featured apps or specialized micro apps we call “Sites.” As long as we get the culture right, we expect to continue to deliver enduring value for our clients.

Shimel: With becoming a publicly traded entity, some companies have found “managing to the street” does not match their own long-term business plans and their customers needs, how does Appian avoid this?

Beckley: Companies, like people, are an aggregation of their habits. Appian’s habit has always been to hold to our long-term vision of enabling every company to be a software company. We are not your typical Silicon Valley tech company. Our roots are in DC, we largely bootstrapped this business, and learned to be good stewards of capital while helping to support the core missions of federal agencies and some of the world’s largest brands. The proceeds following this IPO will be invested back into our business to benefit our customers.

Shimel: What do you see post-IPO being the biggest areas for growth as it relates to new products and services?

Beckley: We plan to invest in innovating and enhancing our platform. While our platform is industry-agnostic, we have recently made, and plan to continue to make, investments to enhance the expertise of our sales and marketing organization within our key industry verticals of financial services, health care and government. We have made, and will continue to make, investments in research and development to strengthen our platform and expand the number of features available to our customers. As we continue to increase the functionality of our platform and further reduce the amount of developer skill that is required to build robust applications on our platform, we believe that we have the potential to expand the use of our platform.

Shimel: Digital transformation is a term that is being used a lot these days. How far along the adoption curve are we on digital transformation?

Beckley: While many speculate that digital transformation is just a tech industry buzz word, in reality, digital transformation is a living, breathing effort. According to a recent survey, digital transformation is a C-level priority and is considered a top focus for almost 50 percent of all companies this year. From Appian’s perspective, we believe that the utilization of low-code software to drive digital transformation is still relatively new and our customers will be able to succeed in their digital transformation efforts by incorporating low-code development.

Shimel: Where does the DevOps market intersect with the Appian business model?

Beckley: Organizations are turning to DevOps to accelerate development and bring an application’s capabilities to a user quicker. The Appian low-code development platform fits into the DevOps model and supports the seven major DevOps categories including code, build, test, package, release, configure and monitor.

Overall, our business model supports the DevOps market; we’re living in a world where citizen developers are playing such an important role in the enterprise and our platform empowers the citizen developer while alleviating developer resources to focus on the more challenging, business-critical developer work.

Shimel: What about containerization and microservices? How do these technologies affect Appian?

Beckley: Appian already uses containers and microservices. Appian’s enterprise customers often require a mix of cloud, hybrid cloud, and on-premise installations. We view containers and microservices as enabling technologies to support the diverse workloads and deployment models required by our enterprise clients.

Shimel: What about security? What challenges does cybersec pose to Appian’s development of their platform?

Beckley: Appian works with some of the nation’s most important and highly regulated industries, therefore we have built a comprehensive security and compliance structure that meets several industry standards. We frequently undergo third-party audits to ensure that we are always operating effectively to protect our customer data.

— Alan Shimel

June 7, 2017
One Team’s Microservices Journey and CD Growth

Dev Manager Vadim Madison published a chronicle of his team’s move from a monolithic application to a microservices model. In the process, the tools and methodologies they used for continuous integration/continuous delivery (CI/CD) had to be expanded and even changed out in several stages. It’s a long read, but with the time, as there are not a lot of people documenting the case of full-on conversion.

One of the more interesting pieces of his work is the software infrastructure they have to build up to cover CI/CD/monitoring of the application. This is a lot more complex than the original application was, and it all must be managed. One of the benefits of DevOps is to make management of these tools easier, and he does talk a bit about scripting it out and implementing APIs to take problem instances out of the pool and determine what went wrong so they can go through the Dev/CI/CD cycle again.

One of the graphics showing integration.

What makes it interesting is where the team found limitations and switched tools midstream. This being a process, Madison at the end alluded to the fact that they have started eliminating TeamCity (or at least limiting what they’re using it for). I think that when most people begin to go high-rate DevOps, or even constant monitored low-rate DevOps, some of the items his team ran into escape their notice until they find an issue. The architectural growth will occur—you are automating more, building more, monitoring more and releasing more. The question is, how far ahead do you look? Until recently, the answer was pretty much, “Not far,” because we didn’t have cases like Madison’s to draw on and see parallels with what we were doing. But that is starting to change.

CI/CD/ARA vendors can help, of course. Collectively they have a lot of knowledge about the lay of the land, and how people are using the tools to tackle the needs of new architectures. But more public documentation such as Madison’s would be great, too.

Even though you’re moving at a much faster pace, looking ahead and increasing the steps taken in the CI/CD/ARA space can provide that added bit of resiliency, and monitoring at a level appropriate to your project’s maturity can add that extra bit of “we know, we can recover.” There have been some spectacular failures that were indicated by monitoring, but the volume of data flowing through monitoring was enough to mask it. Today, the best solution is to monitor at the appropriate level and then feed that monitoring back into the system.

But you’ll be supporting more software infrastructure. The growth of tools is pretty inevitable: As you spread the functionality across machines/instances/containers, you will need to stretch CI/CD/ARA tools to multiple interrelated targets and monitor the overall system and its performance bottlenecks. And for now, the tools chosen will not always be widely known, so a process to bring new Dev/DevOps team members quickly up to speed on the more obscure tools should be on your list of to-dos.

— Don Macvittie

May 12, 2017
I Can’t Go to That DevOps Conference

Last year, I was able to attend 18 DevOps conferences. I saw some awesome presentations, met incredible people and expanded my knowledge of the latest practices at each conference. While my role as the DevOps Advocate for Sonatype enables me to get out to all of these conferences, not everyone has the time, the budget, or the approval to get to even one event a year.

DevOps for the Masses

This is what led me and my colleague, Mark Miller, to found the All Day DevOps conference last year. Our dream was to build a DevOps conference for the masses. We decided to offer 57 online sessions over 15 hours and 15 times zones, and registration would be free. Our initial goal was to see if we could find 1,000 people to attend (because that sounded like a big number at the time), but the idea of a free online event caught a viral wind and we ended up having over 13,500 people register to attend.

Every session delivered during the conference was shared by a DevOps practitioner. We had a simple rule for the conference and that was: no vendor pitches.

Team Time

People also told us that they valued having the chance to talk to other attendees they met at DevOps conferences, so we set up a free Slack channel for All Day DevOps. By the time conference was over, we recorded more than 10,000 conversations between the speakers, attendees and organizers.One of the things that fascinated us most about the conference was that organizations such as Accenture, Capital One, Ericsson, Oracle, Target, Telstra and many others had more than 20 employees attending the event. A few of these had hundreds. None of them needed to approve expenses for travel, hotels or conference fees. They just watched and joined in the conversations from their homes or offices.

Here are some of the folks who spoke at last year’s event across our CI/CD, Modern Infrastructure and Automated Security tracks. This year, we have also added a DevOps in Government track to the agenda.

The event was so successful, we set it on the schedule again. All Day DevOps 2017 will take place Oct. 24. It’s online, it’s free and this year’s event will run for 24 hours. Therefore, no matter where you live, if you have an internet connection, you will be able to tune in to join us.

A Few Things to Know

1. You can register for free at www.AllDaydevopsy.kinsta.cloud. Invite your entire DevOps team to join. Everyone registering will have free access to all 57 recorded sessions from 2016.

2. The CFP is open through May 31. If you have a story to share, we want to hear from you. Remember, no vendor pitches are permitted.

3. All Day DevOps is a community event. Last year more than 40 DevOps meetups and software companies helped us spread the word. For those that helped, we added their logo to the site. Same applies to this year. Apply to be a supporter here.

Please join us for this year’s event!

Finally, a big thank you goes out to devopsy.kinsta.cloud, which helped us promote last year’s event to all of their readers. We are excited to have them helping us to promote the 2017 conference as well!

— Derek E. Weeks

May 9, 2017
Webinar: Microservice Monitoring and Quality Management for Modern Apps and Infrastructures

RECORDING

SLIDES

[slideshare id=74005456&doc=webinar-instana-170330193500]

— Jules Louis

March 30, 2017
From Monolith to Microservices – and Beyond!
Software application development and delivery often involves multiple development, infrastructure and operations teams, each with their own preferred “tools of the trade” for building, testing and deploying code changes

For years, virtualization and cloud technologies have provided agile, on-demand infrastructure. The advent of Microservices promises even more agility– but what is required to take advantage of Microservices?

Join Electric Cloud CTO Anders Wallgren and Trace3 Principal Consultant – DevOps Marc Hornbeek as they discuss what is required to:
- Overcome culture and architecture challenges created when decomposing monolithic applications into Microservices-based applications.
- Coordinate integration, testing, monitoring, packaging, release approval and deployment of Microservices-based applications over elastic infrastructures
- Create a controlled and auditable delivery pipeline to support
  Microservices-based application.
- Prepare for “future” applications, pipelines and patterns.
RECORDING

SLIDES

[slideshare id=72784830&doc=microservicesandbeyondwebinarv2-jessica-170303190452]

— Jules Louis
March 3, 2017
All Day DevOps
Over the past year, I have traveled to and delivered presentations at 18 DevOps events. I’ve also heard that over the past several years, John Willis has participated in more than 200 DevOps events. But not all of us have the time or budget to get ourselves and our teams out to these events where we can learn from other practitioners.

This is why we’ve assembled the All Day DevOps Conference for Nov. 15.

Free DevOps

All Day DevOps will deliver 57 practitioner-led sessions over 15 hours and 15 time zones. No vendor pitches are allowed. To break the travel and budget barrier for you and your teams, we are delivering every session live, online and free of charge. Every session will also be recorded. We are doing this because we want to share global DevOps expertise with everyone.

DevOps Brains

More than 3,500 people have now registered for the conference. We have an awesome speaker lineup covering three tracks: Modern Infrastructure, CI/CD and Automated Security. Here is a sample of some of the great sessions being delivered:
- CI/CD
  - Meta Infrastructure as Code: How Capital One Automates our Automation Tools with an Immutable Jenkins, by George Parris (Master Software Engineer at Capital One)
  - Speaking for the Dead: Critical Positive Lessons from Waterfall and Monolithic Architectures, by Michael DeHann (Former CTO & Founder of Ansible)
  - I, For One, Welcome Our New Robot Overlords, by Mykel Alvis (DevOps Computational Demonologist at Cotiviti)
- AUTOMATED SECURITY
  - Stop Changing Your Password, by Chris Swan (CTO Global Infrastructure at CSC)
  - System Hardening using Ansible: Application Deployment + Configuration Management + Continuous Delivery, by Akash Mahajan (Lead at OWASP Bangalore)
  - Building Codes for Building Code, by Josh Corman (Director of Cyber Statecraft at Atlantic Council)
- MODERN INFRASTRUCTURE
  - Terraforming Your Infrastructure: From Beginner to Semi-Pro in 30 Minutes, Britt Treece (Production Engineer at PhishMe)
  - DevOps Friendly Doc Publishing for APIs & Microservices, by Mandy Whaley (Director of Developer Experience at Cisco)
  - Monitoring, Hold the Infrastructure – Getting the Most out of Lambda, Michael (DevOps Evangelist at DataDog)
Don’t Just Listen, Talk DevOps

One of the big pieces of input we have received from the community is that everyone wants an opportunity to interact. This is why we are building a dedicated team room in Slack for you. Every attendee will have the chance to interact with the speakers in the Slack room. Q&A will be live, online and freely accessible. We will also have Birds-of-a-Feather channels set up for those with questions to be helped by those with answers.

Register Now

If you would like to join us, can you register for free. A big thanks goes out to Alan and his team at devopsy.kinsta.cloud for helping us spread word of the event here. We are really excited to have teams from North America, Europe, Asia, and Australia joining us for the event!

www.AllDaydevopsy.kinsta.cloud

— Derek E. Weeks
October 26, 2016