devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Why Salesforce?

    Why Salesforce?

    Over the past 20 years, Salesforce has become the fastest growing enterprise software platform, and a market leader in sales, service, marketing, integration and custom application development among other areas. Although there are many reasons why a company might adopt or consider using Salesforce, the overriding value proposition is that it provides tons of capabilities out of the box, releases new capabilities at an ambitious pace and allows for virtually endless customization and innovation.

    Unlike with traditional platforms, there’s no need to manage infrastructure for computing, data, network or security, and no need to invest in generic system administration that adds no value for the organization. Add to this the accessible and supportive community and learning culture based around Salesforce’s Trailhead, which enables rapid onboarding and skill development, and it’s easy to see the attraction of this platform.

    Salesforce’s mantra throughout the 2000’s was “Clicks not Code,” and their logo was the “No Software” image which became embodied as SaaSy, Salesforce’s first mascot. You could be a declarative developer using clicks alone and build a data model, business process automation and user interface using drag-and-drop interfaces. This opened the door to an entire new job specialization: Salesforce admins and app builders—citizen developers who were empowered to directly customize the platform to meet their company’s needs.

    As Salesforce grew, they recognized the need to enable custom coding on their platform and launched Apex Triggers, followed by Apex Classes and Visualforce in 2008. Admins continued to configure rich business capabilities, while low-code developers and professional developers were empowered to create customizations beyond the scope of what could be built declaratively. Initially, the code developed on Salesforce was rudimentary: a few hundred lines here and there to accommodate unusual calculations and data processing. But gradually, companies began to accumulate tens of thousands of lines of custom code, especially as legacy applications were migrated from other systems. Needless to say, the “No Software” motto no longer strictly applies.

    In the decade since the launch of Apex, 150,000 companies have adopted Salesforce and moved a staggering number of legacy systems onto Salesforce—which now processes billions of transactions per day. Many of these transactions are part of the core CRM and customer service applications, but a huge number relate to custom applications, making Salesforce one of the largest Platform as a Service (PaaS) providers.

    How is DevOps Different for Salesforce?

    As mentioned before, Salesforce provides both SaaS (Software as a Service) and a PaaS (Platform as a Service). By contrast, much of the focus elsewhere in the DevOps world is in moving from on-premise infrastructure to using IaaS (Infrastructure as a Service). This diagram shows an illustration of the differences between these four modes, and how they represent progressive simplifications of what companies themselves have to manage.

    Figure 1: On-premise systems require you to manage all of the resources yourself. IaaS, PaaS and SaaS delegate progressively.

    Managing the Salesforce development lifecycle requires a unique skill set and approach compared to most other platforms. You can say the DevOps movement was jointly realized by both developers (working in traditional languages such as Java) and system admins or operators (working on traditional infrastructure such as servers and databases). There are thus a vast range of well-established tools and techniques in the DevOps world for developing and deploying code, and for managing and updating infrastructure. Unfortunately, almost none of them can directly be used for Salesforce.

    To illustrate this, let’s look at how teams would manage infrastructure using AWS, or deploy an application onto Heroku (a PaaS product also owned by Salesforce). Every aspect of AWS infrastructure can be represented using JSON configuration. JSON can be used to define which AWS services are used, which data centers they are running in and how they’re configured. The AWS CLI (command-line interface) can be used in a continuous integration tool such as GitLab CI to automatically deploy updates to AWS infrastructure every time the JSON configuration changes.

    Similarly, Heroku provides a platform to deploy custom application code (in Java, PHP, Ruby, etc.) and to specify which services (such as Postgres databases) are needed to support that application. The Heroku CLI can be used to automatically update the application whenever the codebase changes. Heroku also provides a tool called Pipelines that allows you to visualize and manage the entire development lifecycle without requiring a third party CI tool.

    AWS’s infrastructure as code approach is a delight for sysadmins, since it allows them to track changes and automate updates. Similarly, Heroku removes the vast majority of the setup and dependencies that developers would need to deploy their applications. Heroku provides a true PaaS that is ready to receive custom-coded applications built in a traditional way: from the ground up.

    Although we can say Salesforce’s Lightning Platform is a PaaS, it actually works extremely different from true PaaS systems such as Heroku. The Lightning Platform allows you to write custom server-side or client-side code, but that code can only run on Salesforce. Although it allows you to define custom database tables and fields, that schema cannot be loaded into any database other than Salesforce’s. These customizations are effectively just changes to the configuration of one Salesforce instance. It’s therefore more accurate to say every customization you can make to Salesforce is basically a Salesforce configuration change.

    Salesforce is actually just a big application that happens to allow for infinite customization. But this means the tools used for managing other IaaS and PaaS products cannot be used to customize Salesforce. Fortunately however, the release of Salesforce DX means the techniques and principles used with other technologies can now be ported over to Salesforce. That is the focus of the book Mastering Salesforce DevOps that I’ve recently released.

    DevOps in the Salesforce World

    Moving from on-premises CRM software to Salesforce removes the need for servers and manual software upgrades. Consolidating customer support and online community management onto the CRM platform removes the need to integrate sales, support and community applications. Migrating legacy applications onto the Salesforce platform allows those applications to share data and processes with the rest of the business.

    Because moving to the cloud dramatically simplifies many of the challenges in delivering IT functionality, many Salesforce customers have been able to innovate quickly without having DevOps practices in place. But even without the hassle of managing servers and building software from scratch, the inevitable growth of complexity eventually causes companies to struggle with issues such as organizations getting out of sync and delays in deploying functionality.

    Salesforce solves so many IT headaches, it’s almost easy to overlook the fact that it’s created some new ones.

    Salesforce has unleashed the ability for companies to focus on their core competencies, instead of struggling to provide basic IT services. Salesforce admins and developers are empowered to spend their time directly creating business value. But with multiple Salesforce admins and developers working at companies year after year, more and more Salesforce customers are finding themselves drowning in all of that business value.

    If you have tens of thousands of components, each providing business value, but no systematic way of tracking, managing or deploying them, you now have a new form of business pain and chaos. Far too much of a good thing.

    What is Salesforce DX?

    Salesforce DX (Development eXperience) is an initiative begun by Salesforce in 2016 and launched publicly at Dreamforce 2017. The goal of the initiative is to re-envision the development experience on Salesforce with a focus on how to empower their development community with the tools and processes needed to develop safely and effectively.

    Salesforce DX is a very broad initiative, including several main teams at Salesforce focused on environment management, custom coding, developer tooling, APIs and more. Although the Salesforce DX teams tackle very diverse needs, their main focus (at least initially) is to improve the developer tooling and development lifecycle.

    The tools and capabilities included in Salesforce DX are made available for free to all Salesforce customers. In that sense, Salesforce DX is an important complement to Trailhead, Salesforce’s free, self-paced, gamified, interactive learning platform. Trailhead is also a major investment for the corporation. Together these are intended to support the growth of skilled Salesforce professionals and to make it easier for those workers to build and innovate on the platform. These multi-year strategic initiatives help ensure that talent shortages and worker inefficiency will not be the limiting factor on the company’s aggressive 30% annual growth.

    Summary

    Salesforce is an extremely powerful and versatile platform. But it’s unique in many ways and it hasn’t been easy for professional developers to adapt their tools and techniques to working on this platform.

    Salesforce DX is a major strategic initiative to ensure that industry best practices such as DevOps and modular architecture are possible on the platform. But making something possible doesn’t mean the process is straightforward. It’s still early days for most teams working to enable DevOps for Salesforce. Fortunately, there is an enormous amount of research and experience that can be borrowed from the broader IT industry. Combining a flexible, powerful platform like Salesforce with the speed and reliability of DevOps processes can open up entirely new levels of efficiency and effectiveness for teams.

    — Andrew Davis

  • The Phoenicorn Project

    The Phoenicorn Project

    The Unicorn Project is the sequel to the ground-breaking book The Phoenix Project. Most people know the story about Bill the IT manager at Parts Unlimited, who is tasked with fixing a derailed IT project or having his IT department outsourced. The Unicorn Project takes it a step further, with developer and architect Maxine in the starring role, helping Parts Unlimited to develop new products in new markets–the riskiest combination of all. This requires gambles that are only justified when the organization can experiment rapidly, break the rules and deviate from the processes that govern their current–but diminishing–business.

    The content of the book revolves around five so-called Ideals:

    1. Locality and simplicity in our code and organization.
    2. Focus, flow and joy in our work.
    3. Enablement of improvement and achievement.
    4. A culture of psychological safety.
    5. A relentless focus on our customers.  

    These are a natural progression of the themes in The Phoenix Project, in particular the first and third of The Three Ways of DevOps: 

    1. Attending to the performance of the entire system, as opposed to the performance of a specific silo of work or department (related to Ideal 2).
    2. Creating short feedback loops, enabling necessary corrections to be continually made.
    3. Creating a culture that fosters continual experimentation, taking risks and learning from failure; and repetition and practice as the prerequisite to mastery (related to Ideal 3).

    Topics related to the first four Ideals have been explored in other books in the same family of publications, in particular The DevOps Handbook. The last Ideal–customer focus–is for me the most significant addition. It really draws attention to how IT and business have to converge and even merge in order to develop new business models. Meaning that those people-previously-known-as-IT have to up their game and develop a much deeper understanding of the jobs customers need to get done. The business value of DevOps has interested me since I got involved in the movement, and I’ve captured some thoughts in a white paper for the DevOps Agile Skills Association.

    It’s another easy-to-read, fast-moving and plausible story that will undoubtedly inspire the DevOps community. So far so good. But as a facilitator of GamingWorks’ The Phoenix Project DevOps game, it got me thinking how I can incorporate the Five Ideals (and more) into this highly-interactive game.

    My first analysis is encouraging. Starting with the last Ideal and working backwards, the game–that is based on the book–has strong focus on the customer while at the same time ensuring that technical debt (another key topic in the book) is kept under control. Psychological safety comes up a lot in the game–when it’s clear that somebody isn’t really participating, there’s a time out to discuss the importance of people feeling safe to share their concerns without fear for their reputation and position. Continual improvement is hard-wired into the game, with retrospectives after each sprint, leading to hypotheses and experiments for the next sprint. As for focus, flow and joy in our work, we encourage the participants to visualize the value stream and see how work flows from role to role. There’s also plenty of fun, particularly when they hit their revenue targets.

    Locality and simplicity in our code and organization is probably the least dominant Ideal in the game–it’s a non-technical game so there’s no coding, and it’s a small team so almost by definition it’s local. We do discuss, however, the challenge of scaling–which is when this Ideal comes into play. I’ll experiment with the Five Ideals in my next The Phoenix Project games so watch out for further blogs.

    The Five Ideals triggered another association. I was lead editor of the upcoming ITIL 4 High velocity IT module. This is about how digitally-enabled organizations place higher demands on IT, requiring different ways of thinking and working. One of my contributions is the concept of five Key Behavior Patterns:

    1. Help get customers’ jobs done–helping customers become who they seek to become.
    2. Keep raising the bar–taking things to a significantly higher level.
    3. Trust and be trusted–as professional knowledge workers in a healthy workplace.
    4. Accept ambiguity and uncertainty–not scared of not knowing an answer.
    5. Commit to continual learning–all as part of their daily work.

    I believe many practitioners want to work in organizations that foster these behaviors. As such, I see them as aspirations. As marketing legend Seth Godin said, “people like us do things like this.” You can see the similarities with the Ideals: 

    • “Help get customers’ jobs done” equates with “A relentless focus on our customer.”
    • “Keep raising the bar” and “Commit to continual learning” are close to “Enablement of improvement and achievement.”
    • “Trust and be trusted” is the same as “A culture of psychological safety.”

    It is so encouraging to see similar thoughts emerging within different communities. This will hopefully break down the silos that exist in the IT industry and bring us all closer together. All too often, conferences and communities are organized by specialization. They stick safely to themselves and reinforce their stereotypical stories about other disciplines. Praise and power to the rebels who practice what they preach (T-shaping and multi-functionality) and liaise with their industry colleagues, organize joint conferences etc. Evolution thrives on diversity and it would be a shame to see inbreeding in communities, leading to extinction. Let’s not only read The Unicorn Project but also do something useful with it.

    — Mark Smalley

  • Operational Excellence and the Success of Software Deployments

    Operational Excellence and the Success of Software Deployments

    When we talk about best practices for software reliability, the conversation tends to focus on optimizing the applications themselves and the infrastructure that hosts them. The driving idea is reliability must be baked into system architectures and infrastructure from the beginning.

    That’s certainly true. But by focusing too much on the design and implementation of applications, you run the risk of overlooking another crucial element for achieving reliability (not to mention agility and extensibility): a culture of operational excellence.

    It’s only by baking excellence into your organization’s operational culture that you can maximize reliability.

    Let me explain…

    Defining Operational Excellence

    Put simply, operational excellence is a mindset that is embraced across an organization to maximize outcomes and positive results.

    Operational excellence can be reinforced by specific tools and processes, but it’s ultimately a philosophy and a cultural principle. It must be integrated into your organizational culture in order to achieve its full effects.

    Operational Excellence And Software

    Operational excellence is a buzzword that you hear occasionally in the context of business management. It only rarely appears in conversations about software. Nonetheless, the concept has an important role to play in several respects, including making software more reliable and extensible.

    Uniting Disparate Teams

    One of the most pervasive challenges in modern software deployment and management is the fact that every deployment depends on multiple teams. Developers, IT operations, infrastructure engineers and business managers all have a role to play in ensuring that an application is a success.

    Getting all of these teams to work together can be a challenge. The ideal solution, according to the DevOps mantra, is to de-silo your organization by creating a single DevOps teams that oversees development, operations and everything in between. For some companies, that approach will work, but for others, single-team DevOps is not a realistic goal. There will always be some distinction between teams and specializations.

    Yet whether you have a single DevOps team, or multiple teams working toward a common goal, operational excellence can help you achieve the cultural unification necessary to help everyone advance the common good. Operational excellence serves as a cultural goal shared by all teams and team members during the software development and deployment process. By making excellence part and parcel of your culture, you gain a principle that can guide all of your teams, even if they otherwise share little in common culturally—which, generally speaking, is the case; developer culture is not the same as IT culture and certainly not the same as business culture.

    Operationalizing Best Practices

    Another key benefit of operational excellence is that it helps to ensure best practices are actually followed across the software deployment process.

    Most stakeholders in software development and deployment know what they should do when performing their jobs…but they don’t always do it. Your developers might churn out an inefficient function because they are under pressure to meet a deadline and need to deliver something that works, even if they know that they are not following coding best practices. Your IT team may fail to configure granular IAM permissions for a virtual server because they lack the time, even though they know that is not a best practice from a security standpoint.

    Instilling operational excellence into your teams helps to prevent these types of shortcuts. When a culture of excellence prevails, your team will follow best practices, even if they take longer.

    Continuous Improvement

    Human beings are naturally inclined to desire finality. Feeling like we will never reach the end of a task is discomforting (that’s why poor Sisyphus was so unhappy, for example). Yet, this discomfort needs to be managed if your organization is to achieve a culture of continuous improvement. Continuous improvement means your teams constantly find ways to make things better, even if they are already quite good.

    For developers and IT teams, this can be a tough pill to swallow. Developers or engineers who have achieved 99.99999 reliability for their application would probably rather feel proud of what they’ve accomplished than be told they need to add another nine to that figure.

    Still, striving to become even better is what continuous improvement requires. A culture of operational excellence can help ensure that your teams welcome this type of challenge rather than resent it.

    Collective Effort

    When it comes to software development and deployment, personal ownership of any part of the code or process is a risk to the organization. If only one programmer knows how a certain microservice works, or only one IT engineer has the power to create new databases, your organization will lose agility, or it could even end up with a hostage employee situation.

    Instead, software deployment should be as collaborative as possible. Everyone within a given team should understand and (in a pinch, at least) be able to perform everyone else’s job.

    A culture of operational excellence helps to ensure that your teams take a collaborative approach to the way in which they build and deploy software. Instead of letting each individual own part of the process and receive personal credit for its success, operational excellence encourages team members to think of their work as a collective process with collective responsibility for the results. That’s because operational excellence focuses on the success of the organization as a whole rather than individual employees or teams.

    Conclusion

    To be sure, choosing the right architectures, tools and people will do much to help maximize the reliability and effectiveness of your software, but those are only part of the solution. You also need a culture of operational excellence to unite your various teams behind a commitment to best practices, continuous improvement and collective pride in the applications they build and deploy.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • Five Tips for Solving the Technology Skills Gap

    Five Tips for Solving the Technology Skills Gap

    The insightful, and sometimes breathless, predictions regarding digital transformation are everywhere. We are right to be mindful of both the potential and the challenges posed by digital transformation. Digital transformation is increasing the rate of change in every business, in every line of business and even in every role.  

    Digital transformation requires new development practices, organizational culture changes, customer intelligence and focus, empathy and, above all, new ways of thinking. Only when everyone is committed to improving the way work gets done, can an organization thrive in a competitive environment. As organizations continue to grapple with how to prepare their workforce for an increasingly digital world, they have a technology skills development problem.

    Below are five considerations for bridging the technology skills gap brought on by digital transformation.

    Identify the Skill or Development Problem You Are Trying to Solve

    It’s essential that the technology skills development program be aligned in purpose and design with the intended business objective. That may sound obvious, but organizations have a way of accelerating beyond the original scope and intentions. 

    Ultimately, what you are trying to do will determine the combination of tools, content and even organizational commitment needed to be successful. For instance, are you trying to deepen technical knowledge for a set of employees? Or, are you tasked with improving specific performance objectives in data, DevOps and/or security?

    Before investing in training, it’s important to establish the targeted employees, the range of competencies to be covered, the degree of proficiency required and the time frame to complete the initiative. In all cases, build a program that can solve the problem in a time frame that meets the business needs.

    Establish the Performance Objective 

    For nearly all technology skill problems, the goal is performance: the target learners becoming sufficiently competent to perform at the required level. Understanding what the performance standard or measure of success is or will be helps focus all stakeholders on the same goal.    

    If specific performance objectives are required, monitoring a specific key performance indicator (KPI) can be the most valuable approach to determining training success or impact. If the KPIs are not available, using post-assessments can be a useful measure of knowledge gained and can help demonstrate the impact of the training.   

    Leverage Authoritative Content

    It’s important to understand the sources used to create the course material as well as who authored or collaborated on the material. This matters not just because the learning content should be accurate, but also because adult learners are sensitive to the credibility of the source material. Especially in technical areas, IT professionals expect to be provided with material from authoritative sources.

    IT professionals consider current practitioners, or well-known consultants the most authoritative voices on how to use technology. In some cases, industry associations or trade groups have established themselves as authoritative sources in their specific technical areas. Regardless, the source material should be highly reputable and authoritative. 

    Put User Experience First 

    Making learning as convenient for the target learner as possible is essential to a successful learning program.  

    Convenience has often meant anytime/anywhere learning—learners can take courses at home, while commuting, from their desk or wherever they work. This experience should be much like watching a movie on Netflix or Hulu: Learners should be able to start the course at one location, on one device and continue it at another time on a different device from just the right point in the course. 

    Training can also be seamlessly incorporated into the workflow of some applications. Think of it like a more sophisticated, less annoying version of “Clippy,” the Microsoft assistant that provided in-context help for Microsoft Office through the mid-2000s. For some types of applications and technical roles, having a context-sensitive learning engine that can identify and serve up nuggets of learning appropriate to the task can be very useful. 

    Offer the Right Mix of Push Learning and Pull Learning 

    Employers are beginning to realize the benefits of pull learning where IT professionals identify and select their own learning paths. This model allows motivated professionals to acquire skills, gain more responsibilities and, in some cases, promotions and new job opportunities. Employers have realized that when employees self-select a course, it is a strong indicator of self-motivation, and a strong predictor of professional dedication and success.  

    But pull learning isn’t appropriate for every problem to be solved. For example, maybe you need a group to learn the same thing about cloud security or compliance. In such situations, it’s not practical to wait until the target learners are motivated to take the specific courses. It makes more sense to solve these challenges by assigning specific courses to the right groups of target learners, assigning completion dates and monitoring progress.  

    Depending on what problem you are trying to solve, either push learning or pull learning may be more appropriate. 

    Setting Your Organization Up for Success

    Ultimately, successfully navigating digital transformation requires a team with well-aligned IT roles and skill sets. People are the make-or-break element of a high-performing IT organization. There is simply no replacement for people with the right skills, attitudes and traits. CIOs don’t have the luxury of hiring a totally new roster of people with “the right stuff,” so they will have to be creative in using a combination of hiring, mentoring and training, contractors, and partners to create the needed mix of capabilities. 

    Once you have hired and trained the talent in your organization, what’s your plan to help them continue their learning journey for the duration of their career?

    — Mike Hendrickson

  • IT Enables Scale in Digital Transformation

    IT Enables Scale in Digital Transformation

    Few corporate functions have seen their role disrupted as much as IT these last few years. The help desk days are long gone. As digital transformation accelerates, IT is becoming less about outright technology and more about creating capabilities that enable the overarching business strategy. As such, IT is the engine behind any company’s digital transformation.

    Here are three ways IT can advance today’s digital journey by empowering the business from a consultative, strategic position.

    Going Digital While Digitizing

    First, let’s agree on digital transformation’s foundational terms, which understandably elicit some ongoing confusion: “digitization” and “digital,” which the MIT Center for Information Systems Research has described as two discrete yet complementary things. In short, digitization is about leveraging technology to improve or enhance business processes, operations and offer development. By contrast, going digital is about giving customer value to digitization—with the goal of revolutionizing the customer experience and creating new digital business models. What’s the point of digitizing a process or product if the user experience is poor? 

    Balancing these complementary efforts is essential. It is the role of IT to ensure that digitization and digital can happen at the same time. 

    Rethinking the Economic Model

    To keep up, IT must move away from traditional demand-based models, enabling capabilities with a product mindset instead of a time-bound project mindset. The concept of capability (that is, a business area enabled by a consistent set of IT products) is quite critical to avoid creating one-off or point solutions that are just the means to answer to a specific demand. Instead, looking to IT as the enabler of corporate practices that are always evolving and improving (e.g., cybersecurity) is imperative. Embracing Agile methodologies will bring this approach to fruition.

    Pivoting to this kind of a capability-based model requires a modern API-based architecture, which fundamentally is the way out of building and/or replacing monolithic systems. As today’s world requires a fine balance of speed and frugality, a mastery of resource allocation, and a prioritization rigor, we must unburden resources aimed at replacing systems that are working just fine. 

    To that effect, Amazon Web Services has a great architecture principle referred to as “two is better than zero.” In other words, it is better to have two similar IT components emerge from fast-paced, parallel development than nothing due to project bottlenecks and unmastered interdependencies. Even if we want to drive re-use every time we can (and have mechanisms for that), we should not bog down overall transformation due to one weighty project. So thinking in terms of not just tolerating diversity, but enabling it, is a good way to built an architecture that can empower both agility and resiliency.

    Addressing Technical Debt Continuously

    Technical debt is perhaps every incumbent company’s biggest challenge when going digital. The cost of maintaining legacy and outdated systems is high, and heavy technical debt is another obstacle to achieving full digital transformation. Accenture consultants see this every day, describing this burden as a price that “hinders [companies’] ability to innovate and adapt in the digital age.” 

    This is where IT can come to the rescue by having a structured approach and engagement model designed to streamline systems and processes in order to free up resources for reallocation. First focus on eliminating legacy custom-built applications and localized tools based on criteria that are well known and shared (think of a scoring system). Here, again, resource allocation can play its part by ensuring the full cost of those legacies is being recognized by the organization. 

    A huge added advantage of a continuous effort to remove technical debt (beyond cost, the reduction of obsolete systems and a simplified IT landscape) obviously relates to security. Especially at a time when the average cost of a single data breach globally is $3.9 million. In fact, potential cybersecurity and IoT-related physical safety concerns “will pressure CIOs at G2000 companies to increase IoT security spending by up to 25%, temporarily neutralizing business productivity gains” by 2020 (IDC). Redirecting technical debt can offset part of this essential spending on security.

    Accenture notes that 79% of CEOs report that their organization is adopting new and emerging technologies faster than they can address related security issues. IT teams therefore must carry the security torch, determining and implementing ways to make security easier for employees while also protecting the end-to-end digital ecosystem. A continuous effort to reduce the technical debt is one way—among many others—to improve posture. 

    A Place at the Digital Transformation Table

    Indeed, these are exciting times for every business. Digital is all about creating customer value, guided by a better understanding of customer needs deeper in the enterprise. Since providing a great experience is not only about the user interface but also about the ability to mobilize the internal systems in order to deliver at scale, IT experts now have a major seat at the table for revolutionizing the customer experience at scale.

    The essential ingredients to full digital transformation are clear: digitizing and going digital, being able to embrace emerging technologies with an architecture that makes diversity efficient when required and creating cyber citizens that continuously reduce the corporation’s technical debt. Behind the scenes and now front and center, IT is pushing forward the transformation strategy for companies staking a competitive claim in today’s digital economy.

    — Hervé Coureil

  • How DevOps Is Driving the Demand for Cross-Platform Tools

    How DevOps Is Driving the Demand for Cross-Platform Tools

    The demands of modern business mean companies today want choice when it comes to the technology they deploy. Gone are the days when they rigidly used a single environment–instead they want to be able to use the best of technology from vendors and be sure it will work across environments seamlessly. 

    Whether it’s on-premises or the cloud, Linux or Windows, SQL Server or Oracle databases or even at the development tool level, they want their people to be able to use the Integrated Development Environment (IDE) they’re most at home with, yet still be able to share third party tools and resources. This requirement for greater choice is being driven by three key factors.

    The Growth of DevOps

    Firstly, the spread of DevOps is leading to greater collaboration between departments within an organization, as is the rise of the cloud.

    In the past, for example, database administrators (DBAs) and application developers worked in their own silos, with their own technology, without needing to interact. DevOps has radically changed this, bringing them together in teams where workflows merge and complement each other. They need to follow the same processes, such as continuous integration and continuous development, but have very different technology backgrounds and skillsets. DBAs may know Microsoft SQL Server Management Studio in-depth, while developers are used to creating code in IDEs such as Visual Studio. SQL Server experts may also choose to work in Windows, Linux or a combination of both environments. 

    Forcing everyone to use a single environment will clearly be counter-productive and lead to a drop in efficiency. At the same time, however, letting them use different approaches can harm the very teamwork that DevOps relies upon. Instead, vendors need to allow their software to be used and managed through multiple approaches, ensuring that companies get the best out of their people and investments. 

    Technology Everywhere

    Marc Andreessen coined the famous phrase “software is eating the world“ back in 2011. Since then every business has seen technology spread throughout its organization, with digital transformation initiatives increasing the software development required for all departments and functions. At the same time, data has become central to better business operations, enabling brands to better understand their customers, provide an improved experience and deliver more tailored products and services. 

    This has resulted in the rise of full-stack developers who are now responsible for both application and database development. Redgate’s 2019 State of Database DevOps Report revealed that 77% of developers now switch between coding in application languages, such as JavaScript in one moment to writing T-SQL for the database the next.

    A problem arises if different IDEs are required which inevitably leads to an increase in the need for training alongside a decrease in efficiency and performance. 

    Growing Cost Constraints

    In today’s competitive marketplace, every business investment is subject to a high degree of scrutiny to check that it’s delivering a demonstrable ROI. While budgets in the past might have allowed organizations to use different tools or systems in each department, there is a growing need to avoid duplication and the costs that it brings. Open source and free tools are also being widely deployed in even the largest organizations. This drive for greater efficiency obviously needs to be balanced against the skills and experience of in-house teams, who want to be able to use tools they favor and are accustomed to.

    Conclusion

    All of these three factors are driving a new approach from software vendors. Whereas in the past they might have focused on integrating their tool with a single IDE, they now need to offer choice. This allows a common development approach to be adopted while still enabling collaboration across the business, particularly when it comes to DevOps. It preserves investment in the skills and tools that different groups know best, increasing efficiency, yet also eases the introduction of initiatives like full-stack development.

    Driven primarily by DevOps we’re moving into a more heterogeneous world, and vendors need to ensure that they are supporting companies so they can work in the ways they want, with the tools they want, if they want to remain relevant and successful.

    — Matt Hilbert

  • The 20 Best DevOps Podcasts

    The 20 Best DevOps Podcasts

    Skip the whole “starting a podcast is easy, all you need is a computer and a mic” pitch. The truth is podcasting is hard and it takes considerable work to create something special. The low barrier of entry intrigue is a double-edged sword, making it harder for good podcasts to get noticed in the incessant wave of new shows coming to market every day.

    Fortunately, there are podcast fanatics out there who can help curate the signal from the noise to ultimately recommend the best podcasts. I’ve worked in the DevOps space for awhile now, most notably at AppDynamics and Sumo Logic, and also run Discover Pods–a site about podcasts.

    Without further adieu, here are my picks for best DevOps podcasts.

    Arrested DevOps

    Hosted by Joe Laha, Bridget Kromhout, Matt Stratton, Trever Hess and Jessica Kerr, Arrested DevOps is probably the most complete podcast on this list. With over 130 episodes produced, they’ve found a nice balance between giving actionable advice around key DevOps strategies, team management, tool selection and integration along with having truly interesting guests from all over the world on their podcast.

    Episodes typically come out about once a month and hover around 45 minutes.

    Listen: Apple Podcasts | Stitcher

    Software Defined Talk

    Software Defined Talk just crossed 200 episodes, making it one of the most accomplished podcasts on this list. Hosted by the always-amusing Cote, Brandon Whichard and Matt Ray, SDT is likely the most entertaining DevOps podcast you’ll listen to as well. They focus on what’s trendy and what has staying power in the greater DevOps landscape, plus go into news and current events.

    New episodes are dropped weekly on Fridays and are usually and hour to an hour and a half long. On an unrelated meta note, I appreciate how they share their technical podcast experience with their audience including changing their podcast hosting service and frustrations with some of the major players.

    Listen: Apple Podcasts | Stitcher

    Masters of Data

    Hosted by Ben Newton, Masters of Data is almost entirely composed of interviews with industry professionals, authors and more, around the role data plays in their lives. Though the majority of discussions are focused on data within the technology landscape, what separates MoD from others on this list is the diversity. For example, Sarah Guo from the venture capital firm Greylock Partners, talks about how she uses data to make investing decisions. John Visneski from Pokemon talks about how they use data to better ensure privacy. David Shor worked on Obama’s reelection campaign and talks about how data gave them the upper hand.

    Episodes are published about once per month.

    Listen: Apple Podcasts | Stitcher

    DevOps Chat

    In full disclosure, this podcast is produced by the fine folks at DevOps.com, however, it most definitely still warrants placement on the list here. By leveraging their standing within the community–and most importantly as an unbiased third-party–DevOps Chat is able to bring guests on from every vendor to provide a glimpse into how they’re tackling major DevOps issues at their company.

    Episodes are released frequently, sometimes multiple times per week. They’re usually relatively short and make for a quick listen on a commute.

    Listen: Apple Podcasts | Stitcher

    The Changelog

    Billed as “Conversations with the hackers, leaders and innovators of software development,” and I guess I can’t describe it any more succinctly than that. Hosts Adam Stacoviak and Jerod Santo have a good podcast rapport and produce a weekly show (typically 45 minutes to an hour long). Usually, they’re joined by guest in the greater developer community.

    Interview-based podcasts in particular seem to run the gamut of quality. Most outsiders likely think they’re the easiest since you simply need to book a guest and speak into a microphone. However, they require more of the intangibles like interview rapport, research and personality to create a successful show.

    Listen: Apple Podcasts | Stitcher

    Puppet Podcast (Pulling the Strings)

    I typically hesitate to recommended branded podcasts of any kind, but Puppet has earned the respect and doesn’t shill in their show. The podcast mostly comprises of industry discussions in automation and config management. Their latest episode discusses the most recent State of DevOps Report and the larger trends they’re seeing in the market exemplified from the survey.

    Listen: Apple Podcasts

    Azure DevOps Podcast

    Hosted by Microsoft MVP, Jeffrey Palermo, the Azure DevOps Podcast is an interview-based shows with both practitioners and execs specializing in .NET and Windows-focused DevOps roles. Though I don’t quite agree with the podcast description using the words “hard-hitting interviews,” Palermo is able to conduct an interesting conversation with his guests as well as provide listeners with actionable strategies on pushing out new features and monitoring them in production.

    Listen: Apple Podcasts | Stitcher

    Honorable Mentions

    Some of these are no longer in circulation but many of their episodes are usually around evergreen topics and are–at the very least–entertaining listens on DevOps topics:

    • ThoughtWorks
    • Continuous Discussions (c9d9)
    • DevOps Radio
    • Software Defined Interviews
    • DevOps Mastery
    • Software Engineering Daily
    • All Things DevOps
    • Real World DevOps
    • Nice Work
    • The Hanselminutes Podcast
    • Greater Than Code
    • This Developer’s Life
    • DevSecOps Community

    There you have it, my favorite DevOps podcasts. They’ll interview your favorite thought leaders, discuss container strategies, CI/CD and more.

    — Kevin Goldberg

  • Achieving Organizational Change Through Scaled DevOps

    Achieving Organizational Change Through Scaled DevOps

    The rapid pace of technological change has had a major impact on customer expectation, forcing IT decision-makers to adopt agile processes to ensure the continual delivery of innovation. This has led to the mass adoption of DevOps practices, with 77% of organizations indicating they rely on DevOps to deploy software, or plan to, in the near future.

    DevOps is a key ingredient for building and deploying better software faster. It enables developers to spend less time on onerous tasks and more time creating new features that drive competitive advantage and elevate customer experience.

    But, for DevOps to streamline organizational change, it can’t be a one-off initiative. Scaled DevOps requires aligning team members on common goals and best practices and establishing a DevOps maturity model tailored to a company’s individual needs. This is no easy lift and has led teams to abandon DevOps initiatives before they even get started. While the road to scaled DevOps can be daunting, the benefits can have a positive ripple effect across the organization.

    Business

    The business benefits that accompany DevOps are endless. Think: expanding your customer base, spearheading organizational readiness and achieving unmatched speed. As the consumer landscape continues to change, you will be able to adapt accordingly to generate new features and pathways to customers. Plus, DevOps provides a prime opportunity to get more information from your client base and relay it back to developers, equipping your organization with opportunities to learn from its failures and develop a company-wide, reflective model that better accommodates customer demands.

    Once your organization establishes a successful DevOps practice, it will be better prepared to take on other emerging trends and undergo a full-scale digital transformation. With DevOps as the catalyst for change, you can surpass competitors and disrupt the industry with innovative ideas, enabling you to stay ahead of the curve. Once an organization is fully committed to DevOps practices, the company will also enjoy a competitive advantage due to increased speed by empowering your business to provide customers with capabilities faster than rival industry players.

    Culture

    DevOps may require a daunting corporate culture makeover, but it also allows businesses to enjoy unbeatable cultural benefits by improving communication, establishing a foundation for continuous learning and boosting corporate morale with more meaningful work. When effective processes for communication are in place, employees can avoid the misunderstandings and missteps that often lead to failed initiatives and low morale. Once DevOps improves communication between teams, it sets the stage for more collaboration and cross-departmental education, allowing an organization to develop new operational efficiencies and empowering staff with highly specialized knowledge. With reduced inefficiencies, team members are empowered with more free time to create and meet new goals, plus budding talent from competitors will be drawn to your organization’s innovative environment.

    Operations

    Empowered by scaled DevOps, businesses will enjoy huge operational and technical rewards with automation, controlling costs and revamping security practices. Since establishing a DevOps practice requires the successful adoption of automation processes, a DevOps initiative includes the same key benefits that automation boasts by delivering the coveted digital experiences that consumers, employees and stakeholders demand. Automation not only meets these demands, but also sets the groundwork for a DevOps journey with CI/CD pipelines that automate software releases to rid your organization of manual release challenges.

    On the financial front, as your company moves toward a consumption-based economics model for things like public cloud, your DevOps practice will help control costs and environments by alleviating unused tools. In the long run, improved security will also prove profitable because there is no fiscal nightmare worse than a breach. Upon defining your DevOps model, compliance and control are not only maintained, but rapidly transformed through automated policies and configuration management.

    With knowledge of the transformational qualities that come with an effective DevOps approach, IT leaders are eager to adopt DevOps to improve efficiency, boost profitability, deliver superior customer experience and establish a culture of empowerment. However, they must understand that successful DevOps initiatives do not happen overnight. DevOps is reliant on continuous testing and education to ensure that companies can keep pace with their new collaborative culture, rapid delivery process and new technologies. Nevertheless, motivated by the promise of positive business, operational and cultural transformations, organizations will be more willing to prioritize the key credentials necessary to start, and maintain, an efficient DevOps practice.

    — Tim Curless

  • Maintaining Strategic Focus During Agile Releases

    Maintaining Strategic Focus During Agile Releases

    In today’s hyper-competitive world, releasing early and often is a business necessity. When done right, this unrelenting commitment to speed enables product teams to quickly respond to shifting market conditions. But sometimes, agility can lead to a lack of strategic focus. Releases degenerate delivering shiny objects that temporarily fascinate the product or sales organizations without wowing customers. Without strategic focus, releases can:

    • Lack a discernible theme, becoming an amalgam of disconnected features.
    • Introduce incomplete and disjointed workflows.
    • Fail to address long-standing customer requests.
    • Attempt to patch weaknesses rather than building upon strengths.

    When planning product releases the goal is to keep a strategic focus while still rolling out the simplest complete solutions to customer problems. The following set of questions guide us:

    • Will this release show notable progress in executing the company’s strategy?
    • Will this release provide a complete solution to a strategic customer’s problem?
    • Which customer success stories can my team tell as a result of this release?
    • Will this release show notable progress in executing the company’s strategy?

    It’s incredibly important to reduce alert fatigue for our users. Therefore, in every release, we give high priority to our AI features that help with alert noise suppression. This means we sometimes have to make hard decisions, such as deferring new dashboard widgets to later releases. Your company’s strategy may be to add revenue by attacking a market adjacency, or maybe it is to reduce a perceived value gap to a competitor product by bringing feature parity. Regardless, whether your company’s strategy is explicitly defined or implicitly understood, maintaining strategic focus means every release has to further your company’s objectives.

    Will This Release Provide a Complete Solution to a Strategic Customer’s Problem?

    Product management and engineering can build a shiny, new toy, whether that’s upgrading to the latest JavaScript framework, adding some esoteric widget to a dashboard or building a cute Slack bot to get the field and a few customers buzzing. But marketing and sales leaders know they can’t drive more prospects, cross-sells, up-sells and long-term loyalty if they aren’t solving complete problems for high-value customers. Take care to avoid the distractions and focus on pressing customer needs.

    Product teams should do the hard work of conducting customer interviews, surveys, mining community forums and sharing observations with stakeholders to determine how to complete existing features or solve well-understood customer problems. These solutions should allow a user to say, for instance: “Now I can automate my entire workflow, even though I don’t have all the bells and whistles I want.” Such users can turn into customer success stories and references. Prioritize shipping the complete solution in one release, even if that means you have to delay shipping customization options for a later release.

    One of the lessons product managers learn quickly is a release is unlikely to be successful if the field isn’t excited about it. Contrary to our wildest dreams, our users don’t take a day off when we have a new release and walk through every menu function to find hidden features. Without the marketing, sales and customer success teams going above and beyond to demonstrate value, product releases may languish or experience mediocre adoption. It’s not uncommon for users to express surprise upon discovering a feature that solved a problem for them, and which has been available for a while.

    To excite our field teams, we have to tell strategic customer success stories. There is nothing more powerful than telling the team you made a specific user’s life better or helped a customer grow sales. It’s even better if that user can be part of your release announcement to the field, showing his or her enthusiasm and willingness to be a reference. These customer success stories don’t magically materialize at the end of a release. They require a ton of planning upfront and tremendous discipline and focus to bring to fruition. Yet, they bring incredible rewards as the whole company feels rejuvenated and validated when they hear how their work has made a positive impact on real customers.

    Product release planning is a strategic exercise that’s critical to the business. It’s not simply pushing out a bunch of work a product team has accomplished. As a product leader, keeping a strategic release-planning mindset will help focus both the field and product teams’ energy on the company’s objectives. Teams will see the fruits of their labor by driving greater customer adoption of releases. And that’s something we can all celebrate.

    — Kash Noorani

  • Serverless and GraphQL: Build and Launch at the Speed of Thought

    Serverless and GraphQL: Build and Launch at the Speed of Thought

    Websites and apps are now, often, one and the same. Traditional development methods for an online or downloadable app can take months, given the backend development aspects that need to be managed—infrastructure provisioning and management, security, scalability, consistency and more, particularly for companies that have users around the globe and potentially very high usage demands.

    In addition, once the app is built, it can take several days to launch and ensure global availability. Once launched, the app can require ongoing maintenance and supervision to ensure availability and performance, as well as constant fine-tuning of the balance between over- and under-provisioning to manage costs.

    Serverless computing, when combined with GraphQL APIs, is the Holy Grail of application development. These technologies make it possible for developers to build and launch apps lightning fast by removing server provisioning and management concerns. Developers need only worry about building a compelling app with usability features that optimize engagement. Additionally, with serverless and GraphQL, an app can essentially be launched to a global user base within hours or even minutes, rather than days, while avoiding the need to manage servers. Let’s take a look.

    What is GraphQL?

    GraphQL is an API standard for building modern, data-driven applications based on the widely known HTTP Protocol. First created by Facebook in 2012, GraphQL was key to the social media giant shifting its mobile app from HTML5 to a native mobile app. Based on its success, Facebook made GraphQL available to the public as an open-source project in 2015.

    With GraphQL, you define an agnostic Domain Specific Language (DSL) around your data structure in terms of:

    • The programming language you use. As an API standard, GraphQL is open for implementations in many languages, such as JavaScript, Java and C#. You can essentially use the standard with your language of choice.
    • The database engine you use. GraphQL is only concerned with having the data ready, rather than the source of the data and where it is coming from, so you have the freedom to implement a GraphQL API with almost all database engines.

    What’s All the Fuss About Serverless?

    Serverless represents a major paradigm shift in the way we create and run web services and apps. Serverless computing operates in the cloud, freeing developers from the burden of thinking about back-end tasks, such as managing infrastructure, scaling servers and provisioning capacity and resources.

    Below, I’ve listed some specific benefits that serverless provides, looking specifically at serverless databases—many of these advantages are part of other serverless offerings as well. The overall impact is that with serverless technologies, developers only pay for what they use, or what the app uses depending on user demand. Developers can scale up to virtually infinite disk space and compute loads in seconds when traffic spikes hit, and scale back down when users go offline. The NoOps aspect of serverless means maintenance costs and burdens are removed. Additionally, global availability zones allow for replication between different locations and allow you to keep data where it’s needed—close to the user to minimize latency. Built-in encryption means developers can secure their apps with only basic security know-how.

    • Consumption-based billing.
    • Auto-scaling.
    • No operations overhead.
    • Global low latency.
    • Secure by default.

    When these benefits are combined with the advantages of GraphQL, one will notice a perfect synergy between the two technologies. Not only does the process become more automatic, the standard facilitates communication between internal teams and makes it easier for clients to integrate with your software, through:

    • API discoverability and automatic documentation.
    • Consolidation of data.
    • Language and data source-agnostic.
    • Type safety.

    Serverless Plus GraphQL Equals Developer Nirvana

    There are numerous examples of companies that have managed to build faster and cut costs with serverless. One of the most impressive demonstrations is when students in Australia managed to rebuild the census application and handle loads that the official $9 million system could not handle, at a fraction of the cost using serverless technology. GraphQL takes these advantages a step further.

    Airbnb, a company already known for its serverless adoption, claims to be moving 10x faster thanks to GraphQL, while Coursera noticed that their frontend developers found it easier to discover and query new data as their API evolves. These benefits are not just limited to a developer’s own company. For example, GitHub clients can now fetch data more efficiently and more easily thanks to the GraphQL-based public-facing API. GraphQL is even competing with SQL—when databases such as FaunaDB offer a native GraphQL API, users move to GraphQL at a rapid rate.

    Given the advantages of serverless in removing server provisioning and maintenance, and the freedom GraphQL gives developers when it comes to using programming languages and database engines, developers are essentially able to build and launch apps on a global scale as quickly as they think of them. And in the end, don’t we all want our customers to have a better experience?

    — Brecht De Rooms