devopsy.kinsta.cloud

Tag: software engineering

DAOPS Meetup 2021: Software Engineering, DevOps and DevSecOps

DAOPS Foundation—a non-profit organization committed to accelerating global digital transformation through technical standardization—is hosting the first ever DAOPS Meetup on May 18. The virtual meetup will bring together DevOps leaders from Sonatype, DevOps Institute, TARS Foundation and DAOPS Foundation to discuss the latest in software engineering and the latest DAOPS developments.

Here are the four sessions scheduled for the DAOPS Meetup.

ASEM, Next Generation Software Engineering Infrastructure

Software is the core of digital transformation. In the digital era, the way we produce software also needs to be digitized. Forest Jing, chief evangelist at DAOPS Foundation, explains how they plan to help global enterprises build a high-performance, technical organization based on Lean, Agile, CI/CD, SRE, DevSecOps, Cloud Native, etc., by developing the next generation software engineering infrastructure named ASEM.

Best DevOps Practice with TARS

TARS is a high-performance RPC framework based on name service and Tars protocol, also integrated administration platform, and implemented hosting-service via flexible schedule. During this session, Mark Shan, chair at Tencent Open Source and TARS Foundation, will share the best DevOps practice using TARS.

DevOps Hybrid Skills — Upskilling towards EverythingOps

Upskilling is a human endeavor and a key contributor to personal and career growth. This past year was like no other. As we progress through the “next normal” of this decade, one thing is certain—digital transformation relies on human skills transformation. DevOps has continued to shift left in recent years, becoming more integral to operational processes as manifests in domains such as secure-development-focused DevSecOps, secure-operations-focused SecOPs, artificial intelligence-based AIOps, machine learning-focused ModelOps, and data management-related DataOps. As each of these evolves, its specific required skill set is being fleshed out and internal IT staff have the opportunity to upskill to meet requirements. Join Dheeraj Nayal, global community ambassador at DevOps Institute, to learn all about DevOps upskilling.

The Rise of Next Generation Software Supply Chain Attacks

Cameron Townshend, Solution Architect from Sonatype

The adoption of open source in software development has grown exponentially over the past decade. Yet, the time required for hackers to exploit a newly disclosed open source vulnerability has shrunk by 93.5%. As development teams deliver new innovations, adversaries are also upping their game; something we’ve seen in recent high profile and devastating cyberattacks, such as Dependency Confusion.

Adversaries have the intent and ability to exploit security vulnerabilities in the software supply chain—and in some cases plant vulnerabilities themselves. They have increased scale through automation and improved breach success through precision targeting. Cameron Townshend, solution architect at Sonatype, urges developers to fight back by doing the same: automating security directly in the DevOps pipeline.

For more information and to register visit the DAOPS Meetup website.

May 17, 2021
Why Developers Should Care About Resilience

Recently, a friend reminded me of a joke we used to have when we were both developers at a huge software corporation (we won’t mention names, but back when printers were a thing, you probably owned one of theirs). We didn’t develop printers. We developed performance testing and monitoring tools.

We were the dev team, which was completely separate from the QA team and from the Ops team (yes, I’m that old – we didn’t even call it DevOps back then). Support was part of a completely different organization and “business” was something that happened in an altogether different galaxy. That is, until a customer had an issue.

When an important customer had an issue, we definitely felt it at R&D. Managers called hourly to check on status, and we would have intense conversations with the support team who would then, in turn, have intense discussions with the customer. If we, the software engineers developing the product, ended up on the same call with both support and the customer, it was a sure sign that things were bad. You knew that millions of dollars were on the line, and, consequently, that pressure was high. But most of all: you knew that we would do anything we could to solve the problem, because we needed those millions of dollars to be paid, so that we could keep getting paid. And so, we kept the coffee flowing.

This is where the joke part comes in. We used to have a system for managing support tickets, collecting information, tracking time and assigning it to the relevant software or support engineer, so everyone would know who was in charge. Today, you probably use Zendesk, ServiceNow or one of their alternatives. We used a home grown system, of course.

Our joke was this: the purpose of the system was not to track and measure and propagate the handling of customer issues. The purpose of the system was to indicate someone else is now responsible for solving the problem. Or, if you would rather paraphrase one of my favorite Douglas Adams jokes, the issue is now under a Somebody Else’s Problem field.

Because solving customer issues is difficult and frustrating, and being pressured by business could ruin a software engineer’s day. This is because when you’re a happy code monkey, and all you want to worry about is writing beautiful code and releasing cool features and drinking some coffee, solving a customer issue gets in your way.

You end up spending too much time sifting through endless logs, crossing your fingers and trying to reproduce an issue that only happens at 2 a.m. on a Friday, usually when a blue zebra is passing by. Spending your time on a heated support call is less fun than, say, drinking coffee quietly with your friends.

As R&D managers, we understand that our developers want nothing to do with solving customer issues. We want to make sure they are motivated and happy and efficient, and that they are free to challenge themselves by learning the latest buzz-worthy technologies and thinking up ways to introduce those into our product in a way that will make our customers happy.

Additionally, as R&D managers, we are far more likely to understand the business impact of having too many support tickets or having support tickets that take too long to resolve. We know that the loss on such cases is twofold:

1. The customer that faced an issue and is waiting for a solution may become frustrated, and the company may lose their business.
2. Our engineers are busy solving that customer issue instead of delivering new value to the business.

Therefore, as R&D managers, it is our responsibility to make sure that our engineers have the tools to handle these issues as efficiently as possible when they come up. It is our responsibility to make sure they are motivated, and that they understand the business impact of solving a customer issue as quickly as possible. And whenever possible, it is our job to make sure that they make our application as reliable and stable as possible to begin with.

That ensures that we have test coverage, and the right knowledge, practices and tools to ensure that we have as few customer issues as possible to begin with.

Happily, changes in dev culture usually means that “support” and “business” and even “customers” are not as far away as they used to be. When developing a SaaS platform, your developers often have an almost intimate, real-time ability to track what users are doing and how it impacts their experience. The culture of DevOps has done a lot for breaking the silos that used to separate the dev team from the support team, and to make sure that all members of the team engage and understand how the code they write and the issues they resolve help our customers.

I hope you already found the way to motivate your team to solve such issues, and that they have enough time to drink coffee. If you and your team are still struggling, we suggest bringing in a live debugging tool that can help them solve customer issues even faster, by making sure they have all the data they need at their fingertips, and that they can instantly reproduce any issue in a live, remote environment. Live debugging tools give your engineers a developer-friendly experience, and also gives them the power to reduce issue resolution time, too. Now, all you need to worry about is that your engineers have enough coffee.

March 17, 2021
Bootstrapping DevOps for the Internet Computer

All startups face unique sets of challenges and issues at each stage of their existence. The DFINITY Foundation, a Swiss-based not-for-profit with the remit to extend the functionality of the internet, is no exception. Like any new organization, we have had to evolve and adapt our DevOps and other practices in response to different obstacles.

After learning to clearly communicate our vision for an open development platform where software runs directly on the internet, we created a road map to translate this vision into a decentralized architecture with distinct features that could be built and shipped on a periodic cadence. Consisting of five milestones, the road map culminates in a public launch in Q4 of 2020—and we haven’t missed a single deadline despite the disruptions of a global pandemic.

Incorporating a focus on operational responsibility on top of our focus to ship features without losing speed was a major challenge this year ahead of the release of our developer network, called Tungsten. Sustainably bootstrapping operational responsibility for this release, as well as future releases, was imperative.

We’ve all heard horror stories about operational teams that run through a checklist in a perfunctory fashion without identifying the root cause of a problem. Even worse, they are quick to give up and are resistant to launching changes, increasing the complexity of their workload.

Pushing Forward With DevOps

We were determined that this wasn’t going to happen to DevOps at DFINITY, so we embedded these core cultural touchstones into the organization.

1: Create SLOs and SLIs for cross-functional clarity

At the end of 2019, well before there was a service to operate, we started thinking about service level objectives (SLOs) and service level indicators (SLIs). These are critical for providing a common, quantifiable vernacular for R&D and Operations teams to measure how a service should be performing.

An SLI is a clearly defined indicator for one aspect of a service’s performance, ideally focusing on user-visible service behaviors. The SLO sets the target for the indicator, as well as a window of time over which it is measured.

To communicate the SLIs and SLOs, training materials were presented across the organization, including speaking with various engineering teams, discussing best practices at management meetings and giving an overview at an organizationwide meeting. In addition, the leadership of R&D teams signed off on the approach.

To provide clear operational expectations as well as a forcing function, we established an early version of the SLOs as a high-priority OKR.

As an additional consideration, it is crucial that your SLOs reflect aspects of your service that are visible to the user. As Charity Majors, CTO of Honeycomb.io, noted, “Nines don’t matter if your users aren’t happy.” SLOs are not a one-and-done deal; they need to be updated as the service evolves and as your ability to capture the UX improves.

Having SLOs in place gave staffers with operational responsibility clear expectations to fulfill. If the service is performing within the SLOs (and if the SLOs are representative of user happiness), then things are running smoothly.

#2: Engineers developing the software should also help run the software in production

To bootstrap the team with operational and support capabilities, we needed to ensure that we didn’t create a siloed team lacking engineering skills. Operations in this context is a software engineering problem, which meant we needed to involve developers.

The same engineers developing the software should have skin in the game in terms of how the software is running in production. If there are problems, these engineers are in the best position to diagnose them and propose and implement the necessary fixes. Getting organizational buy-in for this took some time.

We emphasized the need for senior engineers to be able to operate the software being built. We didn’t want to fall into the trap of throwing a handful of junior engineers into the deep end without proper supervision or training, so we also established an expectation that all engineers should be able to operate the software irrespective of seniority.

We built two teams of between five and 10 developers in each of our office locations in Palo Alto, California; San Francisco; and Zurich, which were initially staffed with volunteers across the organization. Each week, one team member at each site managed primary operational responsibility for the service instead of their regular project work, and they knew that the entire staff would help if there were any problems. We plan to rotate new people into these ad hoc teams every six to nine months.

#3: Create optimally sized, communicative teams

Operational team size is also important. If the team is too small, people are on-call too frequently. If the team is too large, they will be on-call so infrequently that they will either forget how to operate the production stack or their knowledge will become outdated.

We share status updates through a daily log and informal shared communication channels such as Slack. There is also a weekly meeting to relay responsibility from one person to another.

This has helped us identify capability gaps. With team members based across the world, we’ve come to acknowledge that if a problem requires a team’s expertise outside of its working hours, then rolling back first and investigating later is absolutely fine.

The DevOps team decided early on that we weren’t going to start with 24/7 support, instead providing support during business hours in Europe and the U.S., where the majority of our early-access customers are located.

We’ve been transparent to the wider organization throughout this process, calling out what is and what is not working well, and how we’re working to improve our processes.

Conclusion

We were fortunate that unprecedented global events like COVID-19 didn’t significantly affect our operations. That said, shaping our processes in-person and being physically present for people when they first go on-call would have been valuable, and we definitely felt the impact of losing that. But we’ve successfully bootstrapped our DevOps teams nevertheless, and we look forward to continuing to evolve as a team.

October 19, 2020
Value Stream Optimization: Putting Business in the Driver’s Seat
How value stream can be a major driver of DevOps success in today’s software-only world

Even as DevOps reaches a pinnacle in acceptance (as of 2018, only three percent of firms had not adopted DevOps and had no plans to do so), many organizations are still struggling to get high-quality software out the door. DevOps has been promoted by many experts and consultants as a solution to the cumbersome inefficiencies that were common with waterfall methods. However, as is common for many operational activities, applying a new approach or technology doesn’t automatically resolve entrenched problems.

Nowhere is this more obvious than in value stream management (VSM). This approach, which focuses on removing the waste from processes to increase their efficiency, sounds like a panacea for resolving software delivery challenges. In practice, it often falls short of its goals.

Why is this? There is nothing wrong with the concept of the value stream. The idea of breaking down a complex process into its components and optimizing each one of them, thereby optimizing the chain, is a long-recognized pillar of lean production. In my view, the problem isn’t with VSM or even DevOps.

The problem is that in moving from waterfall to DevOps and/or agile, many organizations figuratively “throw the baby out with the bathwater.” They are uncertain how to adjust for the extreme acceleration that occurs when teams move from rudimentary software processes to modern ones, so they either jettison important elements of software engineering or adapt them incompletely.

Why Continuity Matters

By way of example, consider measurements and metrics. The traceability and proactive remediation enabled by measurements and metrics are two of the most important aspects of software development. However, it’s not just the development and test metrics that matter, but also the business metrics—metrics of quality, user acceptance, security and ease of use. Since the dawn of software development, those two groups of data have been inextricably linked, but some modern software teams appear to have forgotten that lesson.

No amount of process improvement metrics can ensure a software release is secure or that users will like it. Yet, if a major software upgrade is flubbed, it can impact operations so negatively that sales momentum stalls. (If the company sells the software it develops, the ripple effect is even stronger.) Even more disconcerting, after a major data breach, a firm can find itself out of business.

Don’t get me wrong. I am not suggesting that flow and other DevOps metrics don’t matter, because they do—very much. I am suggesting that many teams and their development managers have become too divorced from the business metrics, which can have staggering negative consequences.

From There to Here

In the days of waterfall, development artifacts, defects and other data were warehoused in an offsite location, and after each release (which might take days, weeks or even months), teams would engage in several days of data extraction. Then, a separate team would attempt to map the development artifacts to the defects and enable traceability. After hours or days of organization and cross-mapping in Excel spreadsheets, reports would be generated for management and the C-suite. Once stakeholders and management completed their evaluation, the team would be cleared to make adjustments before the next release cycle.

Now, our development paradigm has changed so dramatically that many teams aren’t giving metrics their due. That’s an issue with defect metrics that could impact the user experience or software reliability. It’s a serious, potentially game-ending problem when the metrics are related to security.

Completing the Value Stream

To create and administer the complete value stream, software teams must be supported in three areas beyond the traditional DevOps framework where iterative development activities are the primary driver of traceability measurements. With these elements in place, management can map their software teams’ efforts to the business metrics that are the final measurement of success:
- Organizations must have a mechanism for integrating development and testing tools so that defect measurements can flow back to the development team in real-time—matching the speed of DevOps.
- Critical software activities that still take place outside of development and testing processes, such as generation and approval of change orders, must also be monitored for inertia, with approvers being held accountable for holding up paperwork that delays releases.
- Security defects must be given parity with, and preferably priority over, all other code defects. All defects that impact the user side, such as functionality and launch speed, are important business metrics. But security must be paramount.
If you are a development team member reading this, or even a development manager, you may think business metrics and the related activities that happen outside your purview, don’t apply to you. I urge you to think again. Software has become a critical pillar of many companies’ operational success, and that connection is only growing stronger by the day. Everyone involved in software development, from the developer to the VP of Operations and on to the CEO, must view the entire process through the lens of business.

— Joe Schulz
June 3, 2019
Bridging the Gap Between ITSM and Software Engineering
Considering the individual roles of IT service management (ITSM) and software engineers, it seems obvious they should work closely together. ITSM tracks internal and external customer issues, and engineering fixes code-related issues (such as defects) that IT cannot fix on its own.

However, more often than not, coordination between these two departments is poor, which—critically—undermines customer response times and damages application satisfaction. It’s important to remember that the quality of customer response isn’t just about speed, it’s about giving customers insight into the state of the issue.

The disconnect between ITSM and engineers—caused by individual priorities and semantic differences—makes this real-time insight difficult. Both teams have individual and shared concerns, and separating these while simultaneously improving collaboration is a big challenge.

Addressing this relationship is an important step in optimizing ITSM and DevOps integration, alongside focusing on IT help desk enhancement requests to product management, and tracking code from build to release and back.

The Flow of Information on Things that Matter

Most of the tickets generated by the IT help desk can be handled internally with no help from engineering, but it’s the tickets that do need help that require consideration. For these issues, there needs to be an open flow of information on the things that matter between these two teams.

IT help desk must give engineering enough information to understand the defect and its impact on the customer. Meanwhile, engineering needs to be able to give the help desk a sense of when to expect the fix, when the fix is done and be able to request more information when required.

Information that should be shared from the help desk to engineering includes the following:
- Severity – Engineering needs a sense of the importance of the defect. If everything comes in as “High Priority,” nothing is high priority. The help desk must understand that engineering already has its own internally generated set of defects, as well as defects found by QA and other sources. For these customer defects to be prioritized and fixed in a timely manner, engineering needs to know how impactful they are to the customer.
- Description – This is perhaps the most important piece of information the help desk can pass along. The more contextual information that can be shared, the better. It’s immensely important to provide engineering with the necessary steps to reproduce the specific defect, which version of your tool the customer is using, the general environment, etc. Sometimes this is best in structured fields, whereas other times it’s important to simply write out everything.
- Screenshots and other visual information – Along with the written description of the problem, engineering often requires logs and/or screenshots. As the saying goes, “A picture is worth a thousand words.”
Now that engineering has the vital information it needs to fix the defect, it has a responsibility to provide useful information back to the help desk:
- Planned release – This should not be a firm commitment, but rather an estimate to give the help desk general timing. While the actual date of the fix may vary, it’s still useful to be able to tell a customer,”This is coming soon” vs. “We realize this is a problem and it’s on our backlog to fix.”
- Engineering status – While this is a single defect to your customer and to them only has one status, there are really two statuses your organization will care about:
  - Status of the ticket in your ITSM tool
  - Status of the defect in your defect tracking/agile planning tool
It’s very important that the ITSM tool contains both statuses to provide more information and context to the help desk. Imagine the benefit of knowing that the defect is “In Triage,” “In Progress,” or “In Verification” and being able to provide that information to a customer.
- Actual release/released – As opposed to the planned release information, this lets the help desk know that the customer’s issue has been resolved. Imagine running a report from your ITSM tool indicating the defects fixed in your most recent release. Your IT help desk can proactively reach out to customers to let them know to upgrade, enabling you to offer more proactive customer communications.
Finally, and perhaps most important, you allow your teams to talk about the “same thing” even when it exists in different tools and they speak a different language. There are four core ways to do this:
- Cross tool tracking – Each artifact in each system should have the ID (and ideally URL) of its twin artifact in the other system. If a help desk representative needs to talk to an engineer about a defect, the rep needs to let engineering know which defect it is in the engineering tool, not just in the ITSM tool.
- Routing – IT help desks often support multiple products, each of which have multiple components that may belong to a different engineering team. The help desk needs some indication which component and/or team should work on the defect. This information will help the IT help desk know which team to reach out to for help.
- Filtering – Not every ticket in the ITSM tool needs engineering help (that’s a good thing). However, there should be some indication on the IT ticket if it has been sent to engineering. You do not want to send the same defect to engineering twice (confusing) or to assume it’s been sent when it hasn’t (poor time to resolution or issue overlooked).
- Communication – IT and engineering need a shared way to talk about a specific defect that they both care about. The closer this communication can be to the native commenting that already occurs, the better. Ideally this is not via email as that communication vehicle does not stay attached to the artifacts in question, meaning information can be hard to find or get lost.
The Benefits

Customers will love it – Improved communication means happier customers. Customers can plan their upgrades with more certainty, and their trust grows since your organization is able to deliver on its promises. No longer will they feel like their issues are being thrown into a black hole.

Better engineering focus – Engineering gets pulled in a variety of directions, contending with feature work as well as internally generated defects. The more information it has, the easier it is to prioritize and deliver more value to customer. Without the ability to share the severity of a defect, you risk two undesirable outcomes:
- The defect is fixed instead of more important work, which hurts all your other customers.
- Other less important work is prioritized, which can threaten your relationship with this customer.
Better trust across your organization – Open communication fosters trust and understanding. Providing insight into prioritization and status let’s your help desk feel part of the development process. No longer will staff feel like they’re sending problems into a black hole with no idea when they will be fixed. Enhanced cross-team communication also helps engineering to avoid feeling like work is simply being thrown over the fence. Obtaining more context around a defect is invaluable.

Next Steps for Total DevOps Integration

To fully integrate your ITSM and engineering teams, there are still (at least) two other processes to implement:
- A method for the IT help desk to provide enhancement requests to your product team: These enhancement requests are similar, but distinctly different from the defects described above. Consequently, they need to be prioritized and triaged by a different team.
- The other process to implement is the traceability from task to code to build and back again. In order to properly inform customers that their problem is fixed in this version of your product, it’s important to correlate features, stories and bug fixes with the actual version of your product that includes them for the first time.
Bridging the gap between ITSM and engineering teams brings your company closer to customers. While making your organization work as a unified whole is an incredibly complex problem, addressing this relatively small—but vital—piece of the puzzle helps you on your journey to integrating your whole software value stream. This change of mindset—combined with connecting all teams, tools, disciplines and processes in an enterprises’ software value stream— optimizes collaboration, productivity, efficiency and, most importantly, value delivered to the customer.

About the Author / Trevor Bruner

Trevor Bruner is a Product Manager for Tasktop Technologies. His background includes experience in financial services, oil and gas and as a Navy submarine officer. Connect with him on LinkedIn and Twitter.
October 9, 2017
Building DevOps Careers: One Man’s Journey, Part 2

In Part One of this two-part series, we introduced former SlideShare and LinkedIn software engineer Sylvain Kalache, who shared his career growth within the two companies. In this second part, we’ll look at San Francisco-based The Holberton School of Software Engineering, which Kalache co-founded to better prepare students to work in a DevOps world.

School Founder, Still a Coder

Kalache still uses much the same coding skills in his new role as he did as an engineer. “I still manage machines, the ones that host our website and intranet and the iMacs that students use,” he says.

The Holberton School of Software Engineering founders removed every manual step possible, using software to automate the admissions process and any process that they could. Even in the classroom, automation rules: Computers automatically review student work on projects.

“Computers test that students’ code works as expected by simulating user interaction, checking syntax and assessing how fast the code executes. For infrastructure in code, computers check for stability, response times and security breaches. By using multiple ratings parameters that are linked to specific skills, the computers collect detailed data about the strengths and weaknesses of each student,” says Kalache.

“We have a lot of our own secret sauce in software automation running the school for us,” he adds. “This requires all the technical skills I used in my coding days including designing, building, configuring, testing, deploying and maintaining software and systems.”

Teaching Methods

The Holberton School of Software Engineering engages students in building each skill they will need for careers in software engineering through use of industry-standard teaching methods. “Methods include deep learning in building features into software products and classical teaching in clear, documented code,” Kalache says. “We have a team of 150-plus mentors who make sure our curriculum is up to date and in sync with what the industry actually does and who coach and share their knowledge with students.”

The Holberton School of Software Engineering uses fully practical methods with no formal teachers or lectures, only mentors. “Mentors are like managers in a workplace. I mentor, coaching students in their learning journey and giving advice when there are issues,” he says.

Students engage in peer learning, working collaboratively on software projects, which encompass the skills they will need to demonstrate in their careers. Successful completion of projects, including solo projects, is proof of attaining the required skills. “Students must defend their projects before mentors with mentors ensuring that every student can present and explain the technical aspects of the project; if even one student can’t explain it, then the group fails on that project,” says Kalache.

“We teach problem-solving and how to learn new skills because there will constantly be new technologies and concepts for our students to understand and master in their careers in the tech world,” he adds. “Professionals who cannot adapt and retrain themselves will quickly fall out of date with technology.”

Readying Students for Careers from Day One

The Holberton School of Software Engineering prepares students to be ready to work when they start their careers. “Graduates of other programs whom I have spoken with have no idea what it is to ship code to production and run a production environment. They are used to academic projects that teachers correct for them,” Kalache says. “That is not how it works in the industry.

“Even boot camps and universities provide minimal practical experience that will make job hunting difficult,” he continues. Smaller organizations don’t have the money to pay someone to learn before starting them working in production. Thus, he says, startups need to execute fast using professionals with mature skills. “Though our students will fail and struggle, they will do it at the school, which will have a much smaller impact than doing it on the job,” says Kalache. Students are exposed to creating, shipping and working with code in production for two years before graduation.

What’s more, real, workday DevOps requires effective communications skills. “Whether it is to introduce the last tool you built, explain what happened during an outage or convince your managers that your solution to a problem is the right one, you need to have oral and written communications skills,” says Kalache. As such, the school runs students through a series of exercises in public speaking, technical writing and documentation, as well as post-mortem communications when dissecting an outage, prepping them even further for their careers and the world beyond the classroom.

May 19, 2016
Building DevOps Careers: One Man’s Journey, Part 1

In 2011, Sylvain Kalache was a software engineer at SlideShare, which LinkedIn acquired in 2012. Kalache was a senior systems reliability engineer (SRE) at LinkedIn, doing project management and planning, documenting and sharing knowledge tools, and adapting himself and his work to the LinkedIn organization and its technology.

Today, Kalache is helping build DevOps careers as co-founder of Holberton School of Software Engineering in San Francisco, where students learn to code through “project-based and peer learning,” according to information from the Holberton School website.

This is Kalache’s DevOps career story, how he worked in and then transitioned from a career in DevOps to a personal and professional investment in helping students to build their DevOps talents toward a lifetime of coding and contribution in software engineering and, hopefully, successful careers.

Software Engineering at SlideShare

“SlideShare was a very small company when I joined. The San Francisco office had only 10 people; I was only the second engineer at that location,” says Kalache. But the DevOps mindset was strong there, he says, and the company had bet everything on DevOps methodologies. In fact, it was the commitment to DevOps by SlideShare and its CTO at the time, Jon Boutelle, from which Kalache learned of the development approach and took to it so quickly.

“Boutelle was looking for full-stack or aspiring full-stack engineers and I was a junior programmer and eager to learn. In a small company like that where you are encouraged to work on every aspect of the product life cycle, it became very clear that I was in charge of taking care of my mistakes,” says Kalache, adding SlideShare expected him to take ownership of his code from design to production.

“Because I was eventually in charge of a lot that was going on with the infrastructure at SlideShare, I had to build and maintain a lot of systems that were serving billions of slide views per month at what was one of the top 100 most visited websites in the world,” says Kalache.

People from the Dev and Ops teams there did not only their own work, but also the work of their companion team. In essence, Dev was both Dev and Ops and, likewise, Ops was both Ops and Dev.

“The SlideShare people were writing their own configuration management code, setting up monitoring of new services and features as they built them, deploying their own code, and troubleshooting code in the production environment,” says Kalache. Ops people helped developers design sound code for acceleration while also giving their code a second look to ensure fitness for operations.

Project Skynet

“The most exciting project I built for SlideShare was Skynet, an automated tool to monitor, scale and auto-heal a system in the cloud,” says Kalache. Skynet was developed to meet several challenges in the day-to-day work of simply being SlideShare and doing what SlideShare does. SlideShare acted on, renamed and translated countless files from one type to another to share them on the site. As with other slide technologies, the tool was a fit for teaching and presentations.

There was no way to know exactly how much users would upload, access or view any slide content at a given time. “There were peaks and valleys in upload traffic with mornings seeing high traffic and low volumes in the evening and on weekends. The SlideShare infrastructure had to scale quickly to encompass and convert common document files at speed. This required adding many hundreds of machines to the infrastructure,” says Kalache, which were virtual machines that spun up in minutes in the AWS EC2.

One purpose of Skynet was to enable precise analysis of log files for transparency into everything from individual file conversions to changes in the entire machine cluster as the environment scaled up or down. The other purpose of Skynet was to use the analyses to auto-heal; in other words, to restore the cluster back to its initial size once the peaks were over.

With many thousands more employees at LinkedIn than at SlideShare, Kalache left many of his duties at SlideShare to others while he dove much more acutely into specific aspects of his work.

Co-Founding a School That Builds Careers

In speaking with his colleagues and representatives from various enterprises, Kalache continually confirmed that organizations using DevOps are in need of lots of engineers but they can’t find candidates who are knowledgeable and experienced. “I was actually recruiting for SlideShare and for LinkedIn. What saddened me was to see a graduate who had just spent half a decade and a lot of money on a master’s degree only to be far from employable,” he says.

Kalache found it hard to find people who knew basic software engineering, DevOps, and how to be an SRE for LinkedIn. “We instead had to hire early graduates who had coding skills and an interest in operations and train them on being an SRE,” he says.

Kalache decided to combine an awareness of alternative teaching methods with his passion for the coding and ops communities to find a solution to how to better prepare software engineers for careers. “After mulling it over for two years, I decided to quit my job at LinkedIn and create the Holberton School,” says Kalache.

In Part Two, we dive headlong into the teaching and learning experiences at the Holberton School of Software Engineering to help students learn and understand the DevOps methodologies and increase their chances for success in their respective careers.

May 17, 2016
An Engineering Think Tank to Change the World

In his famous book “Mythical Man Month,” Fred Brooks says, “Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.”

While being very fond of engineering on the big scale, such as building millions of high-end and yet individually configured cars or double-deck aircraft or space ships, for example, I have always asked myself, why the most promising industry—software engineering—is so often not capable of doing engineering on that scale, too? Or, why are so many big enterprise IT projects painful in so many ways?

With these questions that nobody seemed to be really interested in on my mind, one day I met some higher corporate management, who wondered why the IT department would be so reluctant to follow their lean transformation advice and instead talked about some agile and continuous integration thingy.

From that moment, I understood that everything necessary to radically upgrade software engineering was already there! The biggest problem was that we do not communicate enough—and furthermore, there is no holistic view on the complete IT value chain.

By that I mean we need to create awareness for the value chain, starting with digitized formal models of business processes and written business requirements.

That was how the following chart came to existence, and I still love it. Apparently, most awesome things happen on the borders of separated knowledge domains; you need just to talk to colleagues from departments you’d never talk to! What if we would mix knowledge from big industry, best available process improvement and quality assurance methodology, and apply all this to how we design, build and deliver software?

At first I thought I had found a new perspective on DevOps, but now I believe there could be more to it. Well, now the door to the radical innovation is open! Just imagine: What if we would apply the Internet of Things approach to our industry? Maybe we could close the loop of process improvement in software development and test, moving it to real time and running optimization not by ambiguous frameworks but by hard facts coming from virtual sensors, with unprecedented levels of transparency?

This was how a couple of friends and I came to the idea of our foundation we call SIGSPL (Special Interest Group for Software Production Lines). This public organization is a non-profit think tank, built around three generic domains—Labor Automation, Analysis and Advanced Visualization—which we consider to be the three pillars of the upcoming convergent software engineering in the post DevOps era.

We are sure this sort of thing inevitably will happen, but our mission is to catalyze these processes to make radical innovation happen intentionally and faster, so we all can build information technology that rocks!

We are a small team of six with some infrastructure, publications at our blog and a well-established yet growing knowledge base. We would like to reach out to more like-minded people to let this idea grow and change the world. Our plan is to foster further exchange and discussions between DevOps experts and other specialists “unexpected” in this context, such as production lines and supply chain management experts, Six Sigma Black Belts, 3D artists, hackers, venture capitalists and many, many others.

Our proof that we are not ponding to nowhere is our magic triangle diagram, showing some well-known tools we map to the three generic domains, which are also of high interest for venture capital. Our question to the world is, What would appear in the middle of this triangle in, say, five years?

About the Author/Peter Muryshkin

Peter studied M.Sc. in Applied Computer Science and works in management consulting roles focusing on complex analysis and customer satisfaction, including IT Business Analyst and Change Manager. His current scientific research focus is digital transformation applied to the field of software engineering in large distributed organizations.

LinkedIn: https://de.linkedin.com/in/muryshkin
Team blog: http://sigspl.org/blog/

February 25, 2016