devopsy.kinsta.cloud

Tag: developers

  • Blockchain: A Threat to DevOps—and How Engineers Can Respond

    Blockchain: A Threat to DevOps—and How Engineers Can Respond

    Blockchain is one of the hottest topics in the IT world today—and that creates a challenge for DevOps professionals. Here’s why, and what DevOps engineers can do to remain relevant.

    Blockchain, Fat Protocols and a New Generation of Applications

    To understand why blockchain threatens to decrease the role played by DevOps engineers in software platforms, you have to understand the difference between blockchain-based applications and traditional applications.

    That difference was summed up most famously in an article by Joel Monegro about “fat protocols.” Monegro convincingly argued that prior to the introduction of blockchain technology, most software stacks were composed of “thin protocols” and “fat applications.”

    What he meant was that in most traditional web applications, the majority of the value and functionality lies in the application itself, rather than in the protocols on which it runs.

    In other words, if you write a PHP application, most of the time that you invest and the value you create center around the application code. The protocols that allow the application to work, such as HTTP, are relatively simple and uninteresting.

    In blockchain-based applications, by contrast, the magic happens chiefly at the level of the protocol. The main job of these applications is simply to access that protocol. As a result, the applications themselves are relatively unimportant.

    How It Changes DevOps

    What this means for DevOps is that, if blockchain becomes as central to the software platforms of the future as its proponents hope, application code will become much less important than it is today.

    By extension, the people who write and manage that code—DevOps engineers—will have less of a role to play in software deployment.

    If you take a look at how most existing blockchain platforms operate, it’s easy enough to see how this trend plays out. The amount of effort required to write and maintain a basic “smart contract” application that runs on the Ethereum blockchain, for example, is pretty minimal. You don’t exactly have to be a DevOps genius to churn out some if-this-then-that code that interacts with Ethereum.

    The same is true of an application that writes data to the Bitcoin blockchain to record a real estate transaction, for instance, or one that timestamps a document to a blockchain to create a record of the document’s existence.

    In these use cases—as with almost all use cases associated with the blockchain—the role played by DevOps engineers is relatively small, because there is not much code to write or manage to deliver the platform’s core functionality.

    Blockchain-Proofing DevOps

    Yet, if the blockchain revolution does come to pass, it won’t necessarily be bad news for DevOps experts.

    Even though the core application code required to interact is minimal, crafting platforms that are secure and provide a solid user experience takes more work. This is where DevOps engineers can help.

    One of the most glaring problems with many existing blockchain platforms is that their interfaces tend to be difficult to use. Related software security problems are also well-known.

    In addition, some platforms have performance and scalability problems. Bitcoin advocates like to talk about how digital currency will make transactions much smoother, but the reality is that it can take hours to confirm a Bitcoin transaction. That’s a big problem if you want to buy and sell things with Bitcoin.

    Arguably, these issues originate in part from the fact that many of the people currently designing blockchain platforms are good at recognizing how decentralized, distributed databases can drive innovation, but less adept at writing, maintaining and scaling software and the databases that power it. They are not, in other words, DevOps people.

    By helping to build out blockchain applications so that they are actually usable, secure, efficient and scalable, DevOps professionals can ensure themselves a role to play in the platforms of the future. At the same time, they’ll help the technology transition from its current state of hype into something that can be used to solve everyday problems.

    — Chris Tozzi

  • Securing Third-Party and Open Source Code Components: A Primer

    Securing Third-Party and Open Source Code Components: A Primer

    The increasing popularity of open source code continues to be a boon for developers across the industry, allowing them to increase efficiency and streamline delivery. But there are security risks to be considered when leveraging open source and commercial code components, as each carries with it a significant risk of becoming the enemy within, creating a vulnerability in the program it helps build.

    Sacrificing Security for Ease of Use

    While the many benefits of open source have been well-touted, the sheer prevalence of code components (open source and commercial) across industries is underestimated. CA Veracode recently found that 83 percent of developers use code components to build web applications, with the average number of components per application at a whopping 73.

    Considering the fact that the vast majority of developers build applications with code components, the number of those familiar with the risks of doing so is startlingly low. A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.

    Furthermore, only 43 percent of developers reported being aware of the industry-accepted OWASP recommendations for preventing the use of components with known vulnerabilities.

    Where Does Responsibility Lie?

    One clear issue in this software development practice is that responsibility for securing code seems to fall on everyone—and, sometimes, no one. Forty-four percent of respondents claimed that developers are responsible for the continued security of code components, while 31 percent reported that they expect security to handle this task.

    This lack of preparedness and miscommunication leaves the door wide open for bad actors to swoop in and take advantage of vulnerabilities that could so easily be fixed.

    How, then, can teams ensure the security of applications built with code components? The solution lies in three key steps:

    • Start with education: Software development teams must have the tools and training necessary to ensure the code they write is secure. Educating developers on the risks associated with open source and commercial code components is a start, but prioritizing security training and ongoing education is the key to long-term success. Tapping the security team to lead trainings for their developer colleagues is a good way to embrace peer knowledge-sharing and break down silos between the two teams.
    • Introduce clear processes: To alleviate miscommunication and confusion, organizations must implement clear processes for secure software development. Knowing what an application is built of is the first step, as teams can’t secure what they don’t understand. This may seem obvious, but CA Veracode found that only half (53 percent) of organizations keep an inventory of components. Code components should be thoroughly vetted before being worked into an application and then should be added to a working inventory. Managers should be sure each part of the maintenance process has a clear owner on the team so responsibility is always clear. Consistent testing and patching are also best practices when it comes to security.
    • Drive innovation with DevSecOps: All of this comes back to integrating security into the entire software development life cycle (SDLC) and implementing DevSecOps, because a team that operates in silos will never be able to push out secure code. The development, operations and security teams each provide their own unique and critical contribution to the software development process, and combining forces will result in the best possible product.

    While taking the time to secure applications from the perils of code components may slow down development in the short term, safeguarding your organization and its software assets is invaluable in the long term.

    — Pete Chestna

  • 4 Bad Habits DevOps Administrators Fall Into

    4 Bad Habits DevOps Administrators Fall Into

    The concept of DevOps is central to any organization’s ability to deliver applications and services quickly and efficiently. As it gains traction in many high-profile organizations, DevOps administrators must work to integrate DevOps practices, tools and techniques into a wide range of teams, from development and support to operations and management. Completing this implementation seamlessly leads to better productivity and a smoother overall workflow.

    Bad Habits Derail DevOps

    But along the way, administrators tend to fall into bad habits that affect their ability to deliver these services effectively and efficiently. Here are a few of the most common habits that need to be broken.

    Working in Silos

    Some DevOps teams work in silos, in which development isn’t just one team but many. Think about a group project where everyone divides and conquers on tasks and at the end comes together to integrate different parts, which in turn have different formats, styles, etc.

    This is a bad habit that needs to be broken as it produces an additional level of complexity, with everyone working to solve their own issue at hand in their silo. Operations then struggle to unify the activity into a consistent process. This, coupled with occasional tensions between development and IT operations over different approaches to infrastructure and competition for resources, creates opportunities for failure. As the growing emphasis on DevOps places an added burden on infrastructure teams already struggling to cope with the digital transformation of their organizations, unification will be key to success.

    It is also true that DevOps can find success in small organizations where teams of people are focused on smaller, one-off IT projects, rather than the enterprise as a whole. These smaller teams have the luxury of sticking to themselves and the allowance to work on sequential projects, while their projects don’t scale up to the enterprise stage because they don’t have to. But smaller organizations such as these also likely won’t see much of a difference if they were to adopt a DevOps approach.

    That difference will be most noticeable in substantially larger organizations that see software release cycles rapidly changing on a daily basis. It is imperative for these organizations to avoid silos and to instead have pronounced team roles, better communication and the ability and willingness to break free of old habits that only cause chaos and confusion in the rapidly evolving delivery cycle.

    Planning Too Much, Too Soon

    Success requires continual improvement and refinement, rather than an initial push for certain changes without an overarching plan. The focus of administrators looking to implement DevOps should be on doing all things continuously by starting small.

    Early focus should be on selecting one or two new DevOps teams that start a new initiative. Then, with these new teams in place, you can build on successes and work through challenges slowly, and begin to scale this through the organization. In the beginning of the process, it’s also important to identify one person such as director of operations or chief planner who can be responsible for seamlessly integrating DevOps into your project. This lead owner can then work project by project, setting goals and showing the rest of the team the results in real time. Insight into the progress will allow the team to see their work paying off, and in turn, make it possible for them to realize the benefits of scaling up slowly.

    You need to know what the business problem is and the anticipated benefits, therefore measuring every factor that contributes to DevOps success. DevOps promises an array of automation. This can’t be achieved in a single attempt or overnight. Enterprises have to focus efforts on continuous integration, following it with continuous delivery and eventually continuous deployment.

    Believing Implementation is Easy

    After admins are finally swayed by the promise of DevOps, a belief often held is that the implementation of the practice is smooth and easy. And while DevOps can often lead to a simpler life for specific jobs in IT, the reality is that in many instances, the ease of deployment comes at a cost. It can shift an imbalance of responsibility for production control and quality management to the operations side, and burden the team rules and processes if IT departments fail to understand how to adapt.

    As with any process in any organization, the amount of effort required to support software delivery is a constant. Often, administrators fall into the habit of believing DevOps will handle itself. But if you are managing a large enterprise, you will have teams accountable for quality, performance and change management. The difference with DevOps is the way in which automation is leveraged to place control in the hands of application development teams and redefines the relationship between operations and development. This is a good thing, but the administrators need to be there every step of the way in the process.

    Failing to Take Full Advantage of Continuous Integration and Delivery

    Continuous integration and continuous delivery (CI/CD) are key to successful DevOps teams. However, a bad habit many DevOps teams can fall into is failing to take full advantage of all the CI/CD benefits. The process must to be fast and efficient, as anything that slows down any part of the process increases the cycle time and slows down delivery. To break the habit, DevOps teams need to focus on eliminating bottlenecks in their pipeline to then facilitate agile development processes.

    Your CI/CD pipeline allows for the chance to administer efficient automated testing into your process, but shouldn’t stop at continuous delivery and continuous integration. Another step in doing all things continuous is continuous improvement. DevOps teams and administrators are constantly evolving to fit the needs of the pipeline, and it is imperative that teams spend some time every day discussing and hashing out the small things that can be improved upon. Over time, these changes—no matter how small—will have a profound effect on the enterprise and overall quality of morale between administrators and their teams.

    — Matt Geddes

  • What Google’s ‘Digital Wellbeing’ Means for Every App Developer

    What Google’s ‘Digital Wellbeing’ Means for Every App Developer

    One of the big themes to emerge from Google’s recent I/O conference was Digital Wellbeing—the notion that technology should be a positive force in our lives, and that we need ways to disconnect from apps when they suck up too much time or distract us in other ways.

    Google is taking the idea seriously, and developers should, too. The fact that the company is encouraging people to spend less time with its services should be a wake-up call that every developer needs to think carefully about how they design, build and test their applications.

    To understand why Google’s digital wellbeing initiative is significant for all developers—not just those building for Google platforms—it’s helpful to look at some of the features announced in support of digital wellbeing, many of which are coming in the next version of Android.

    The first is the app dashboard, which will allow users to see at a glance how much time they spend on their phone, how frequently they use different apps and how many notifications they get. Android also will provide new options for silencing notifications, and easier ways to turn on do not disturb mode.

    Another new feature is an “app timer,” which allows Android users to set limits on how much time they spend in an app. When you reach your daily limit, the app icon is greyed out to remind you not to use it again. Google’s YouTube app is getting a similar timer that reminds you to take a break after an hour’s continuous viewing, or however long you choose to set it for.

    It was unthinkable a year ago that Google would encourage people to take a break from their smartphones, since mobile ads are one of the primary ways it makes money. But times have changed, and Google’s digital wellbeing initiative reflects a wider public awareness that technology is not an unbridled force for good.

    “We’ve reached an important inflection point in computing,” CEO Sundar Pichai said at Google I/O, “and it’s made us even more reflective about our responsibilities.”

    Microsoft CEO Satya Nadella expressed a similar sentiment at Microsoft Build, calling for greater responsibility in the technology industry. “None of us want to see the future that Huxley and Orwell imagined,” Nadella said, referring to dystopian authors Aldous Huxley and George Orwell.

    So what does this mean for developers? It means we need to have a greater awareness of the impact the technologies we build will have on users, and to provide the best possible experience with everything we do.

    That means we can’t bombard people with alerts and notifications just to make them spend more time in our apps. People are tired of the constant nagging, and those tricks now work against you. We also need to maximize ease of use, so users can accomplish what they need to do quickly and move onto the next task. Don’t be the app that makes people think, “I waste too much time in this software; I’m setting the timer.”

    Most of all, developers need to provide the very best user experience they can. There were 3.5 million apps in the Google Play store at the end of last year, so there’s no shortage of choice about which to use. If your software is buggy or unintuitive or triggers too many alerts, your app will be among the first to be silenced or uninstalled.

    Google’s focus on digital wellbeing has raised the bar for all of us, and that’s a great thing. But it means developers need to redouble their focus on the user experience. People don’t unquestioningly love their phones anymore; there’s greater awareness of the downsides that constant app usage can bring, and developers need to think about this changing environment as they design, build and test their software.

    — Fred Stevens-Smith

  • Red Hat Positions PaaS as Cure to Heal DevOps Divide

    Red Hat Positions PaaS as Cure to Heal DevOps Divide

    Red Hat is making a strategic bet that IT organizations increasingly will rely on platform-as-a-service (PaaS) environments to make a broad range of distributed services available to developers, which would eliminate friction without enabling IT operations teams to maintain control.

    Paul Cormier, president of products and technologies for Red Hat, said IT organizations are realizing PaaS environments such as OpenShift have evolved into a platform through which a broad range of curated distributed services can be exposed to developers by IT operations teams. That capability is critical because, otherwise, developers simply go around the IT operations team to download libraries. IT operations teams before too long are asked to support applications of uncertain provenance that in many cases wind up duplicating functions.

    As appreciation of the role PaaS environments play in enterprise IT, Cormier said Red Hat is increasingly having conversations with CIOs and other senior IT leaders who are trying to bridge the historic divide between developers and IT operations teams by exposing a broad range of curated distributed services via well-defined application programming interfaces (APIs).

    Red Hat is expanding the types of applications that can run on OpenShift alongside traditional 12-factor applications. In fact, by embracing Kubernetes container orchestration software, Red Hat is effectively obliterating the line between a PaaS and container-as-a-service (CaaS) environment, Cormier said, adding OpenShift makes it possible to build and deploy those applications on-premises or in the cloud as IT organizations deem best, based on cost, data gravity and regulatory requirements. Serverless computing frameworks will make it possible to bridge those environments by invoking an event-driven framework to take advantage of, for example, cloud bursting in a heterogeneous hybrid cloud, he said.

    In fact, Cormier noted more IT organizations will mix and match internal and external services, as each platform tends to run different classes of application workloads better. For example, IT organizations may want to be able to invoke one type of artificial intelligence (AI) service on one cloud over another based on their performance attributes.

    Traditional enterprise IT organizations are not looking to eliminate the need for IT operations teams, he said. Rather than have developers take over IT operations, most organizations would prefer to maximize the amount of time developers spend building and testing applications. The need to build more applications faster than ever will force IT leaders to separate those concerns to eliminate much of the internal friction that results when developers throw application code over the proverbial IT operations wall, Cormier said.

    Most IT organizations have yet to embrace a PaaS environment broadly. There tend to be pockets of adoption. But most applications today are still built and deployed without employing a PaaS environment, mostly because PaaS environments are viewed by many as being too prescriptive in terms of dictating application development workflow. Red Hat is betting that with the rise of microservices-based applications based on containers, many IT organizations will finally decide to trade a little less control in exchange or for much less IT infrastructure complexity.

    — Mike Vizard

  • Open Source: Is Your DevOps Org Vulnerable to an Equifax-Style Hack?

    Open Source: Is Your DevOps Org Vulnerable to an Equifax-Style Hack?

    More than half of the Fortune 100 could be at risk of falling prey to the same kind of hack that caused devastation at Equifax last year, and it all comes down to poor open source component governance.

    A new report out from Fortune reports that in the year after Apache Software Foundation issued an update to its Apache Struts framework to fix a well-known and critical deserialization vulnerability, more than 10,000 organizations downloaded the vulnerable version instead. Among those were 57 percent of the Fortune 100, according to numbers provided to Fortune by Sonatype.

    The vulnerability is best known to have triggered the catastrophic breach at Equifax in 2017 that exposed the records of 148 million people. It’s a doozy of a flaw—a command injection vulnerability that allows for unauthenticated remote code execution—the kind of opening that gives attackers to gain a powerful foothold in affected systems.

    “Seven months should be enough time for organizations to install the necessary patches and it’s unfortunate that so many still choose to download the older vulnerable versions,” said Nick Bilogorskiy. “There is really no excuse for this.”

    This news should be sobering to DevOps organizations. Increasingly, they’re turning to an assembly-focused mode of software delivery that relies heavily on open source components rather than developers reinventing the wheel with new code. It offers a wake-up call for DevOps organizations to get serious about tracking and securing the third-party code they use.

    In a recent DevSecOps survey conducted by 451 Research on behalf of Synopsys, 40 percent of organizations don’t perform any kind of software composition analysis on their software. That’s problematic, because it means that organizations often don’t know when vulnerable open source components such as Apache Struts are woven into their code base.

    More disconcertingly, even fewer organizations have systems in place that can actually control when, where and what open source components are used within their software development. According to a different DevSecOps survey conducted by Sonatype, 62 percent of organizations don’t have any meaningful controls over which components are in their applications.

    It’s a disconcerting statistic, considering the sheer volume of open source component use in development today—whether in DevOps shops or not. In a talk titled, “We are ALL Equifax” at the DevOps Connect event held at RSA conference last month, Derek Weeks highlighted the fact that open source component download requests have increased 87 times in the last 10 years.

    “The growth rate and consumption volume is massive. And it’s coming into your organization,” Weeks told the audience. “And as a result of this behavior the applications your developers are building are now 80 percent to 90 percent open source components—built from code you did not write from scratch.”

    Sonatype’s survey shows that almost 1 in 3 organizations this year suspect or have verified that they’ve suffered from a breach related to open source components in the last 12 years.

    — Ericka Chickowski

  • DevOps Transformation: Leave No Ops Behind

    DevOps Transformation: Leave No Ops Behind

    In adopting DevOps, it’s easy to forget what you know

    Have you ever found yourself struggling to explain something that you know how to do without a moment’s thought? I’m not talking about the amygdala, the part of our brain that initiates the automatic “fight or flight” response. No, I’m referring more to the muscle memory-type behaviors that we’ve collected through life and, likely, pay little attention to while executing.

    Things We Take for Granted

    Muscle memory is awesome. Through the magic of muscle memory I can type fast (occasionally with okay-ish accuracy). It enables me to drive in peak-hour traffic without having a nervous breakdown, and it’s the only way I can ski down a tree-lined path without ending up in hospital.

    It’s through training, practice and repetition that we can carry out an increasing list of mundane tasks without being distracted from the bigger picture. In contrast, consider the expanding influence of DevOps across organizations, and how we’re pushing developer principles and practices onto operational facilities that have never been exposed to such. We’re asking people to break a habit of a lifetime and to think like a developer practically overnight. This can create some significant speed bumps in your operation transformation toward achieving continuous deployment pipelines.

    Type Mismatch Error

    On one side we’ve got infrastructure operations, where we’ve seen two decades of little change in the way services are provisioned and managed. Heck, for the most part, spreadsheets are still the source of truth—spreadsheets without versioning!

    There’s no “commit log” trail, no integrated testing and definitely no consistency across the vendor technologies that must be managed. Imagine what root cause analysis after an outage looks like? A team huddle for a round of “Who touched it last?”

    To software engineers, it must seem like the Wild West but, it’s important to acknowledge that this problem is largely the fault of the technology vendors. Until the principles and practices of DevOps shone a very bright light on operational inefficiencies, infrastructure operations weren’t challenged to increase the speed of business. Hence, the technology vendors hadn’t been pressured to evolve.

    A New Hope (Yes, Like ‘Star Wars’)

    Most infrastructure vendors have responded to the DevOps calling by re-architecting products in support of programmability. Many of them have even done an alright job of it, adhering to RESTful standards and publishing API schemas. However, there’s one key element that’s missing, and will be the cause of further challenges if not addressed.

    To an experienced developer, operating with declarative interfaces, idempotency and continuous integration is practically muscle memory. But to infrastructure operations, it is completely foreign. Progressing with the kind of operational transformation required to achieve continuous deployment is possible but only though closing this operating model gap.

    “Give me a Swiss army knife, and MacGyver I do not become,” said I at DevOps Enterprise Summit 2017.

    As the lines between development and operations increasingly blur, be super-aware of the development principles and practices that are just a part of life for the software engineers. To close the operating model gaps, run workshops for your pals in operations. Teach them all the fancy words. Show them how to manage their config files and architectural notes in a code repository, so they can familiarize themselves with the tooling.

    Most importantly, leave no ops behind!

    — Nathan Pearce

  • 5 Resources for JavaScript Developers

    5 Resources for JavaScript Developers

     Javascript (JS) is one of the most widely used and beloved programming languages in history. This can be attributed to its fairly light learning curve and impressive functionality. Designed by Brendan Eich in 1995, the language has seen steady gains in use for more than 20 years.

    JS itself is a high-level and weakly typed language, which means it is powerful and less prone to errors than other coding languages. It achieved early success and is now integrated on both the client side and server side.

    Most applications and OSs come pre-built with JS development capability. It has become ubiquitous in the web development market and continues to be the strongest and most popular web language out there.

    With that in mind, here are five resources for JavaScript developers:

    Codecademy

    Codeacademy is one of the most invaluable resources a programmer can have. It offers tutorials and lessons on hundreds of topics and provides copious amounts of examples to bolster your programming skills. JS has its own page at Codecademy filled with lessons and coding tests to hone your skills and promote better learning.

    Codewars

    If there is anything that can hone your programming know-how in real-life situations, it’s Codewars. This handy website has weekly challenges to conquer in JS submitted by real people. It puts JS developers in the hot seat and allows them to deal with situations that they may find in real-life work environments.

    It also challenges the knowledge of experienced programmers and enhances their practical skills. Troubleshooting assistance is another big help for programmers just starting out, as it helps identify the small mistakes that can prevent compiling code.

    MDN

    The Mozilla Developer Network (MDN) is a remarkable resource for all JS programmers as it continually updates with the best practices for coding. It has a gargantuan community and is constantly evolving to fit the needs of newer applications.

    For developers, MDN provides unique and incredibly detailed documentation on everything from developing for traditional web to mobile web development. The MDN Web Docs has no equal when programming JavaScript, as it guides you from beginner to expert effortlessly, it seems.

    Libraries

    This is where JavaScript really comes into its own as a powerful platform and highly functional language. JS has a library for everything from GUI to to form applications.

    The most popular library is JQuery, which is a DOM (Document Object Model) manipulation framework designed to make all parts of a webpage customizable. JQuery, like the other libraries, seeks to simplify syntax and provide greater readability across the platform. This makes JS an incredibly customizable language that makes coding easier without losing the functionality of the language.

    Code-Alongs

    One of the most underutilized tools in the programming field, code-alongs make coding much easier than trying to teach yourself from a book or learn from a lecture. During code-alongs, programmers will code live and share their thought processes as they do certain things.

    This especially helps new developers who stare at a screen and can’t figure why that goes there. For experienced developers, it can offer an insight to different strategies that they might not know otherwise. Regardless, code-alongs are incredible tools made by individuals for the sole purpose of fostering a love for programming.

    Conclusion

    Programming jobs today usually require a knowledge of various languages, but almost always JavaScript is a requirement. Its usefulness make it one of the must-learn languages for all coders hoping to make a living. To make life a little easier, and JS a little stronger, there are many resources that can be utilized.

    JavaScript is an incredible programming language entirely deserving of its recognition. It is also a necessary tool for programmers of all styles and philosophies. To that end, resources abound for JS and should be used to their fullest. The true usefulness of JavaScript is its amazing community and incredibly involved developers that make JS the programmers dream. If there is any language you should learn now, it’s JavaScript.

    — Josh Althauser

  • Salesforce Details Integration Plan Post-MuleSoft Acquisition

    Salesforce Details Integration Plan Post-MuleSoft Acquisition

    Salesforce this week announced it will plunk down $6.5 billion to acquire MuleSoft, a provider of application integration software currently used by more than 1,200 organizations. Once the deal is complete, MuleSoft will continue to operate as a unit of Salesforce with current MuleSoft Greg Schott continuing as CEO.

    However, there will be two integration platforms once the merger is completed: MuleSoft will continue to offer its Anypoint platform that can be deployed on-premises or accessed as a service, while Salesforce plans to unfurl a separate Salesforce Integration Cloud based on the Anypoint platform.

    Schott said the merger will accelerate digital transformation projects that in many cases are hampered by developers writing custom point-to-point code at a cost of more than $400 billion a year. By relying on an integration platform, he said, organizations will be able to take advantage of an application network to unlock the value of data locked in legacy systems faster using a standard set of application programming interfaces (APIs) than they would if the two companies had simply decided to form a technology alliance.

    The reason for two separate integration platforms comes down to how different customers engage with MuleSoft and Salesforce, he said. The two companies have a roughly 60 percent customer overlap. That means a significant portion of the MuleSoft base is not integrating applications involving software-as-a-service (SaaS) applications from Salesforce. The Salesforce Integration Cloud will be targeted specifically at customers that are, for example, making use of Salesforce Lightning low-code application development tools to create applications that extend the core capabilities of the Salesforce application portfolio.

    In addition, MuleSoft provides a complementary capability to the Heroku platform-as-a-service (PaaS) environment that Salesforce already owns.

    Salesforce estimates moving into the application integration space will increase the size of its available market by more than $20 billion through 2022. But the company acknowledged that MuleSoft has as of late been operating at a minimal loss—its sales grew 58 percent last year to $297 million, but that’s a fraction of the total available market. Salesforce is betting that its sales staff combined with an ecosystem of partners will be able to drive the revenue MuleSoft currently generates higher by several orders of magnitude.

    However, competition across the application integration category is fierce. Not only is there no shortage of options, but many developers often prefer to write custom code than incur the cost of employing an integration platform. As digital business transformation projects accelerate, Salesforce is essentially arguing that the pace of integration required will make it impractical for developers to continue writing custom code. The rise of microservices also creates a requirement for integration at a level of scale that is difficult to keep pace with when employing custom code.

    The degree to which digital transformation coupled with microservices will transform application integration remains to be seen. But it is apparent that the need to integrate disparate sets of code using a structured set of DevOps processes has never been greater.

    — Mike Vizard

  • DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    Much of the conversation around digital transformation revolves around technology. But the new wave of technology this era has ushered in has also made a big impact on the way organizations, and the teams that comprise them, function.

    This impact on corporate culture has paved the way for the widespread adoption of DevOps, which has broken down silos between developer, quality and operations teams and streamlined the software development process. The next step? Integrating the security team to ensure teams are shipping software that’s actually secure.

    Here are a few ways security teams can better support their developer counterparts:

    Understand How Software is Being Made

    Development teams are under increasing pressure to ship software fast and frequently. Security teams should identify ways to help developers keep up with the rapid software development life cycle (SDLC), while making sure security isn’t sacrificed for the sake of efficiency. Understanding the SDLC for your company is key to finding ways to help that make sense. Have discussions with your development leaders and influential developers to find some ways to win. Create a pilot program with a friendly development team and pour all of your effort into making them successful. Nothing breeds success like success.

    Act as Consultants and Partners

    Developers are taking on more responsibility when it comes to the security of the code they write, which has alleviated some of the pressure put on the security team to secure an entire organization. This has changed the way security teams function and given security professionals the opportunity to act as consultants to their peers in other departments.

    Security team members should approach their developer counterparts with an attitude of enablement. Offering security best practices, problem-solving strategy and general advice will help developers become more confident in their ability to secure the software they build.

    Base all of the above on the security problems they actually have. Don’t preach. Use data from your own application scanning to tailor training. Fill a room with pizzas and developers and talk to them over lunch about problems you can help them fix. Make it conversational. Ask them how they would like to be helped.

    Embrace Ongoing Learning

    Developers have a lot to learn from their security counterparts, but developers can teach security professionals a few things, too. Setting up peer-sharing sessions where both groups can learn from each other will foster an environment of collaboration within the enterprise. Security teams can share threats related to code and specific programming languages and help developers think more like hackers. Developers can share insight into the SDLC and best practices for using code components.

    Combined, the security and development teams should also request support from the leadership team in offering additional educational resources and training.

    Breaking down the silos between development, quality, security and operations to create a true DevSecOps culture will take adjusting on all sides, and it all starts with people. Highlighting the benefit of working together (increased security, streamlined processes and ultimately a better product) is the best motivator.

    — Pete Chestna