devopsy.kinsta.cloud

Tag: Salesforce

  • Copado Launches DevOps COVID-19 Initiative

    Copado Launches DevOps COVID-19 Initiative

    Copado, a provider of a DevOps platform building and deploying applications on top of Salesforce software-as-a-service (SaaS) applications, will make its platform available for free to anyone working on applications to help combat the COVID-19 pandemic.

    In addition, Copado has launched a virtual DevOps training center and opened its DevOps community to anyone in the Salesforce ecosystem by making DevOps certifications available for free for 90 days to anyone who can pass an online examination. Previously, Copado charged $250 per certification.

    Andrew Leigh, senior vice president for marketing and alliances for Copado, said the goal of the Copado Cares program is to train more than 10,000 individuals how to implement best DevOps practices on Salesforce platforms this year.

    In terms of providing free access to its platform for building applications, Leigh said Copado is following the lead of Salesforce, which has launched its own Salesforce Cares initiative that provides free access to select cloud applications.

    Leigh said that Salesforce applications will prove more relevant in the weeks and months ahead as fledgling digital business initiatives that organizations have launched rapidly become the foundation on which business continuity plans are now based. With more individuals working from home, many businesses need to deploy additional digital marketing and customer support applications rapidly, he noted.

    The only way to achieve that goal is to embrace low-code development tools such as the ones provided by Salesforce, Leigh added. Those tools are already integrated with a suite of core applications, which Leigh said means IT organizations don’t need to write entire applications from the ground up. Instead, they can use low-code tools in combination with best DevOps practices to accelerate the development and deployment of applications.

    In the case of health care, Leigh added that a foundation of battle-tested software-as-a-service (SaaS) applications is crucial because new COVID-19 applications being rolled out need to work reliably the instant they are deployed. Beyond the reliability of the core platform, it’s more critical than ever to employ best DevOps processes to ensure those applications have been thoroughly tested, he said.

    Of course, network access to cloud applications can be uneven when everyone is working remotely, However, in time many organizations will increase the amount of bandwidth being made available to critical customers and end users alike. In fact, the economic uncertainty created by the COVID-19 pandemic is likely to accelerate the rate at which organizations have been embracing cloud applications that are consumed on a per-user basis.

    In the meantime, it remains to be seen how long the adverse economic impact of the COVID-19 pandemic might be or to what degree relief measures being put in place by countries around the world might mitigate it. Regardless, it’s apparent that organizations that rely on digital processes are more resilient. In some cases, such as the online delivery of entertainment and education services, there has been dramatic growth. The degree to which that growth can be sustained, of course, depends heavily on how much money consumers are willing to allocate to these services when millions of people are unemployed. Whatever the outcome, however, it’s going to be a brave new world of application software.

    — Mike Vizard

  • 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

  • DevOps Chats: Demystifying Spinnaker VM Baking, with Salesforce

    DevOps Chats: Demystifying Spinnaker VM Baking, with Salesforce

    Spinnaker Summit 2019 Preview: As you use an open source tool like Spinnaker, the more you develop best practices and learnings. These are useful to share with others internal to the enterprise and other open source users.

    Jing Vergara, principal software engineer at Salesforce, joins DevOps Chats to share a preview of her upcoming talk “Demystifying Spinnaker VM Image Baking and Deployment.” Jing shares with us what to include, and not to include, when baking a VM image, how to avoid configuration drift and how to deploy to multiple cloud providers using Cloud-init files. Jing also shares how to use open source Packer templates with Ansible, Chef and Docker, and how to build your own Packer templates.

    Jing Vergara’s talk is on Sunday, Nov. 17th at 10:45 AM PT. Spinnaker Summit 2019 is San Diego on Nov. 15-17.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Jing Vergara, who is principal software engineer at Salesforce. Now, Jing is going to be talking at the Spinnaker Summit in San Diego in November, and she’s gonna be talking about a really interesting topic, “Demystifying Spinnaker VM Image Baking and Deployment.” Now, don’t think we’ve changed into a baking show. We’re baking VM images, and that’s what Jing’s gonna tell us a little bit about, that whole process—pipelining and creating VMs and baking them. [Laughter] So, her talk is on Sunday, November 17th, at 10:45 a.m.

    Jing, welcome to DevOps Chat.

    Jing Vergara: Thanks, Mitch.

    Ashley: Great to have you.

    Vergara: Thank you for the opportunity to have me talk here.

    Ashley: Well, I’m honored you’re on. Thank you for being here. Tell us about yourself. Tell us a little bit about what you do and maybe what parts of Salesforce product or code that you work on.

    Vergara: Sure. So, I’m part of the continuous deployment team at the company. We offer Spinnaker as a Service for all of the organizations within the company. And I help teams onboard their delivery pipelines into Spinnaker.

    Ashley: Oh, interesting.

    Vergara: Yep, and as part of my job, I also build custom extensions to Spinnaker to support their internal business needs.

    Ashley: So, you’re kind of the Spinnaker service center expert person or group that everybody goes to for help implementing Spinnaker. Is that close?

    Vergara: Yeah—very, very close, yes. So, my role within the team has been changing, but yeah, it has transformed into that one. Another thing that I do for Salesforce is that I represent Salesforce at a couple of the Spinnaker special interest groups for stakes insured so that I could learn more about upcoming features of Spinnaker, so we can leverage those in our roadmap as well so that we know we can offer it to the business.

    Ashley: Mm-hmm.

    Vergara: And then we also contribute back to the ________ and let them know what would and would not work for us as users of Spinnaker.

    Ashley: Well, and I noticed in your bio on the Spinnaker site, you have a Master’s in Computer Science from the University of Illinois at Urbana-Champaign. I used to live not too far, from there, though I didn’t go to that school. [Laughter]

    Vergara: [Laughter]

    Ashley: That’s a very strong C.S. degree, and it sounds like you’re putting it to good use with Spinnaker and DevOps style deployment with these kinda pipeline creation.

    Vergara: Yes, right.

    Ashley: Excellent. Well, tell us a little bit about what—so, we’re talking about your talk. So, describe for us a little bit about what are some of the things that are maybe a little mystical that need demystifying about Spinnaker VM image baking and deployment. What are some of the things people don’t know that you usually have to help them understand with, “Here’s how it works and here’s how we do it”?

    Vergara: Sure. So, for companies that are traditionally in a bare metal world where you don’t use VM images, it’s kind of a definite shift in the mindset, right?

    Ashley: Mm-hmm.

    Vergara: So, the way I usually explain it to them is using the baking metaphor, right? So, when you talk about baking, you think of putting the ingredients together like flour, salt, what have you, right? You form a dough, shape the dough, then you cook it. You start with a base ingredient—like, again, the flour—and you mix it up.

    So, in the VM world, when you bake an image, you start with that base OS image. You add your other ingredients, which means installing your applications or your agents to run on that VM. And then you have your standard or common configurations and possibly some data, right?

    Ashley: Mm-hmm.

    Vergara: You add them all up in the VM, you create a snapshot. So, that snapshot, you can now call it the VM image. So you can save this image into a store, and once you have that image, you can use it for deployment. So, deployment, it’s basically building or provisioning one or multiple VMs out of that same image.

    Ashley: Okay. Now, leading into this, the thing that kinda kicks it off is that, I’m not sure how it works at Salesforce, but is it something like a Jenkins process that then kicks off this creating of the image? How does that work?

    Vergara: Right. So, we have our continuous integration system. So, we have a few and we’re standardizing that at Salesforce as well, right? So, we have those artifacts built by those CI systems. We have our Docker images so they get stored, we put them into the cloud, and then we have triggers. So, we listen for those changes. So, Spinnaker supports a Pub/Sub subscription that triggers the pipeline. So, then, once we have those architects, we can start the baking process.

    Ashley: Great. Excellent. Well, that makes a lot of sense. Think of it as all of the pieces of software, OS on up, that are ingredients, right? Just elements of what’s gonna go into that image.

    Now, I imagine this is something that’s happening frequently if you’re doing a lot of deploys, right? Is this happening every time that you do a deploy or just as part of the integration process, and then it may go through a deployment process, too, or how frequently would you see this running?

    Vergara: Yeah, so it’s for every code change that gets checked in, right? Ideally, you would want that change to go all the way, so for continuous—again, for continuous delivery and deployment, that’s the ideal process. Check in, generate the artifacts, and deploy that artifact, create a baked image out of it, and then go and deploy it.

    Ashley: Okay, great. So, this is—

    Vergara: Right, so, but—yeah, yeah, right. But like, when we say delivery and deployment, of course, you know, there’s release management and change management policies at every company that says, “Okay, this is actually good for production deployment,” right? So, some of them are continuous deployment up to development or test environments, but for production, we still want to have that gate system in there.

    Ashley: Mm-hmm, yeah.

    Vergara: And Spinnaker actually supports it really well, you know? It’s got those manual judgment stages that you can add into the pipelines to get those kinds of approvals.

    Ashley: Yeah. Well, we’ve had some other folks talking about some of those stages like Run Job and Webhook and some of the capabilities that are built in.

    Vergara: Yes.

    Ashley: Easy to extend as well in Spinnaker. So, I think one of the things that you’re planning on talking about in your talk at Spinnaker Summit is maybe some lessons learned or best practices that you’ve figured out from doing this a lot at Salesforce. Any thoughts on that you want to share with us about the kind of best practices you’re gonna get into in your talk?

    Vergara: Sure, yeah. So, some of the best practices that I’d like to share with you is more around the baking and deployment. So, for example, when you do baking and never, ever bake secrets during bake time. [Laughter]

    Ashley: Yeah. No tokens, no keys, no certificates, no—

    Vergara: Exactly. Yes, yes. So, that’s very, very important. So, those kinds of sensitive data, you can actually perform that during the deployment stage. There is a trap stage there during deployment where you can go and, you know, connect to a secret store, like, Vault, HashiCorp’s Vault, right? So, you can pull down those secrets and install it on the resources or the VMs, right? So, that’s the safer way to go about it rather than baking it during bake time.

    And then another thing as well, you know, as much as possible to avoid configuration drift, right? So, if you have any common or standard configuration, be it your application configuration or your OS configuration, right, do it during the baking step, right? So, as much as possible, limit those VM configurations towards them. Again, you can do it during deployment.

    Ashley: Mm-hmm.

    Vergara: And then, for companies that support multiple cloud providers—so, for example, you need to go and deploy to, say, Amazon Cloud or Google Cloud or other clouds that are available and supported by Spinnaker, you can use Cloud-init files so that it’s not tied to one particular provider and you don’t have to repeat your bootstrap steps during that same time. So, you write your script once, your Cloud-init file, and then you can use it in those different cloud providers, so that’s, I think, that’s very, very helpful.

    Ashley: Now, is that capability something that’s built into Spinnaker if you write your script corrects, and I think you said init file for each—

    Vergara: Cloud-init.

    Ashley:—each cloud, Cloud-init.

    Vergara: Yes.

    Ashley: Is that something that, it’s a feature if you know about, you can use it up front and design that into how you’re writing your scripts?

    Vergara: Yeah, so, there’s—there are fields within the Spinnaker deploy stage where you can put that in. So, in, I think in GCEVMs, you can use the user data field in the deploy stage, and then in AWS, there’s the metadata field.

    So, the field kind of differs by provider, but it’s the same concept, right?

    Ashley: Mm-hmm.

    Vergara: So, you put it in there, you plug it in. And then, during the bootstrap process of those VMs, I think the OS has the support Cloud-init, though, so when they choose an OS, make sure it’s got the Cloud-init, and then Cloud-init will pick up those files and then launch the steps or commands from what you have in those Cloud-init scripts.

    Ashley: Mm-hmm, great. What are some of the things that people that are maybe new to Spinnaker or new to creating VM images and doing baking, what are some of the typical struggles someone might have that would be helpful to come to your talk for?

    Vergara: Right, so I experienced the same thing when I started out with Spinnaker. I’m like, “Oh, this is all new to me! How do I go about this?” [Laughter] So, one of the things that I’m gonna share in the Summit is, like, “Hey, you know what? Spinnaker actually uses Packer, it’s a HashiCorp tool that actually performs the baking behind the scenes.

    Now, Spinnaker offers a set of Packer templates, right? So, those are the very basic ones. And it actually varies per provider. So, you can only use one at a time. So, if you’re building for, say, GCP, then use the GCP Packer template. And if you’re using AWS, you have to use a different AWS Packer template.

    Ashley: Mm-hmm.

    Vergara: So, and then, if you have a more advanced use case, you can actually customize and build your own Packer template, so that’s one of the powerful teachers of Spinnaker as well, right? So, if you end up—like, you know, so for in-house, you use Chef or Ansible or Puppet. There are Packer templates that can use those kinds of provisioners, but you have to go and deploy those into Spinnaker.

    So, at the talk, I’m gonna share how you can deploy those custom Packer templates. So, there are a couple of ways on how to do it. So, one is the simpler way, but it’s kind of limited. Those Packer templates are stored like Kubernetes secrets in Spinnaker, so it’s got a limitation in size. So, if you have complex scripts or Packer templates, then you have to deploy it as a sidecar container.

    Again, I’m gonna share those tips at the Summit and give more details around it.

    Ashley: Mm-hmm. Yeah, folks may be familiar with Packer, too, it’s an open source project in and of itself for creating images, machine images.

    Vergara: Yes.

    Ashley: Great. Are there some other struggles that you find folks typically have, or may have when they’re new to this?

    Vergara: What else? So, Spinnaker by itself mostly focuses on releasing software changes, but it has a very flexible pipeline management system. Like, at Salesforce, we actually use it for building resources such as load balancers, DNS records, topics, queues. You can actually create custom job stages to perform those.

    Ashley: Mm-hmm.

    Vergara: So, we found it really awesome, because we can rebuild a full environment carrying down all of those existing resources, running the same set of pipelines that we can deploy together with those infrastructure resource setup. So, we can build it up right away, right, and then it also answers our scaling requirements. Because, you know, large scale enterprises such as Salesforce, you know, we have to build all of these resources and deployments. We’re talking about thousands of servers across different regions and geographical locations.

    Ashley: Mm-hmm. You know, sometimes tools, open source, or even commercial tools that are highly flexible and very powerful, sometimes with that comes complexity, so it helps to have some guidance, some experience mentoring from someone like yourself that’s gone through that process and can help you kinda get through it and understand how to use it, how to get things done, right?

    Vergara: Right. So, Spinnaker has a Slack channel. So, you know, when people like me or others who are new to Spinnaker have any questions, we go and ask in that channel. There’s a few channels there that are specific to certain features. So, for example, if you’re struggling with templatizing pipelines, then you go into the Pipelines as Code channel, right? Or if you have questions about how to use Kubernetes in Spinnaker, then you use the Kubernetes Slack channel.

    That was very, very helpful for us, especially in the beginning when we were trying to figure out how things are working.

    Ashley: Mm-hmm, I’ll bet, I’ll bet. How long have you been using Spinnaker, then, at Salesforce?

    Vergara: We started our journey last year.

    Ashley: Okay. [Cross talk]

    Vergara: Late last year, so almost one year now. [Laughter]

    Ashley: Wow, okay.

    Vergara: Yeah.

    Ashley: Wow. I bet a lot has happened in that one year. I know one of the things that you’re planning on also talking about is some contribution ideas for those that might want to help make Spinnaker better. And those are things that you—ideas you had or lessons you’ve learned implementing Spinnaker there, I assume?

    Vergara: Right. So, some of the contribution ideas that we have is with regards to a new effort called Kill. I’m not sure if you have interviewed the speakers.

    Ashley: I haven’t yet, but I may. [Laughter]

    Vergara: Okay. Yeah, so I’ll let them—you know, I won’t steal their thunder.

    Ashley: Don’t steal their thunder—okay, great. [Laughter]

    Vergara: [Laughter] Right, so, it’s one of those, they’re focused more around the managed delivery, so that’s when. Another contribution idea is centered more around each of the providers. So, again, if you’re building for one provider, it’s a different, totally different stage. So, for example, like GCEVM, right? So, they have their own deploy stage for that. And then AWS, they would have their own deploy stage for that. They’re kind of not, like, at par right now. Like, you know, they focus on certain things.

    I think another contribution there is trying to add more options or features into that, so it can fully support that provider. And so, for example, for GCE, I think one of the features lacking there, if I remember correctly—or they might have fixed it. But it was, say, so if you have a persistent disk and you want this particular persistent disk, then it’s not supported. It always creates a new one. So, it doesn’t give you an option to actually reuse an existing one that you’ve built earlier. So, things like those. I think that would be important.

    Same thing with AWS, right? So, there’s some features for EC2 VMs during deployment that could be added in there as well.

    Ashley: Great. I’m wondering, too, thinking about your talking that’s coming up, who are the kinds of folks that would be, get the most out of it, coming to your—obviously, people that wanna perform this function, but is that usually, is it developers, is it DevOps engineers, is it CI/CD automation specialists? Who are folks that would get the most out of your talk?

    Vergara: It would be around the Spinnaker administrators within their companies. So, if they want to learn how to configure Spinnaker to enable features for baking and deployment, then they would be the ones who would learn the most out of it. But I would say, like, all the DevOps engineers who want to figure out how they actually use Spinnaker for baking and deployment as well. Like, how do they set up their pipelines?

    I’m gonna give a demo on how it actually works from start to finish so that they can have a visual. Sometimes, you need that visual to say, “Oh, yeah! Oh, that’s how it works!” Right?

    Ashley: [Laughter] Mm-hmm. Well, that guidance is very helpful. And I can see, too, what you’re saying about the folks that are obviously administering Spinnaker in that deploy process are ideal to attend, and of course, other DevOps engineers automating and wanna know how this part of it works certainly would be good to go as well.

    Well, I wish you the best of luck. I know you’ll do real well. You obviously know, have learned a lot and know a lot from your experience at Salesforce. So, I wish you the best.

    Vergara: Well, thank you. Thank you, Mitch, again, for the opportunity for having me talk here.

    Ashley: Well, absolutely. Thank you for being on. I wanna thank my guest today, Jing Vergara, who’s princ—I can’t say it [Laughter]—principal software engineer at Salesforce. There, I got it out. Now, Spinnaker Summit 2019 is November 15th through the 19th in San Diego, and Jing’s talk is on Sunday, November 17th, at 10:45. It’s titled, “Demystifying Spinnaker VM Imaging Baking and Deployment.”

    So, thank you for joining us today for this DevOps Chat podcast. This is Mitch Ashley with devopsy.kinsta.cloud. Have a great day, and be careful out there.

    — Mitchell Ashley

  • DevOps Chats: Debugging Spinnaker Apps, With Salesforce

    DevOps Chats: Debugging Spinnaker Apps, With Salesforce

    Spinnaker Summit 2019 Preview: Debugging production issues in any environment can be challenging, and Spinnaker has its production learning curve. Problems aren’t always replicable in a smaller environment, and debug messages can be verbose and confusing to triage what’s happening.

    Our DevOps Chat guest Chuck Lane, Salesforce lead software engineer, is giving a talk on “Debugging and Profiling Spinnaker Applications Live” at the Spinnaker Summit 2019. In Chuck’s talk, you’ll learn skills like remote JVM debugging, custom profiling builds and the magic of figuring out what’s going on with a multithreaded microservice using htop.

    Chuck’s talk is on Saturday, Nov. 16, at 3:40 PM PT. Spinnaker Summit 2019 is Nov. 15-19 in San Diego.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Chuck Lane. He’s a lead software engineer with Salesforce.com. He works on Sales Cloud, which is the Salesforce you and I use, know and love, or our CRM capabilities. Chuck is talking at the Spinnaker Summit 2019 in San Diego, and his talk is about debugging and profiling Spinnaker applications live. And I think live means, like, live while they’re running, in production, and see what’s going on. We’ll explore what that is. This talk is on Saturday, November 16th, at 3:45 p.m. in San Diego. Chuck, welcome to DevOps Chat.

    Chuck Lane: Thank you. It’s nice to be here.

    Ashley: Excellent. Awesome to have you here. Would you start by just introducing yourself? Tell us a little about you and what you do at Salesforce.

    Lane: Yeah. So, my name is Chuck Lane. I am, as you mentioned, a lead software engineer. And basically, my chief responsibility at Salesforce is to help bring Salesforce into using Spinnaker for our public cloud based deployments. So, as we make a transition to try to move away from first party architecture and move over into the public cloud, one of the technologies that we’re using to do that is Spinnaker and I’ve established myself as a subject matter expert in Spinnaker. And so, I kinda help to bridge the gap between the traditional development and deployment cycle and what that looks like using Spinnaker in a containerized world.

    Ashley: Okay, great. You used a term there I don’t know if I’m familiar with. You mentioned something about moving from first party architecture to the public cloud. What’s that mean about the environment you’ve been in that you’re, and what you’re moving to?

    Lane: Yeah. So, basically, what I mean there is that, historically, Salesforce has owned their own data centers, and we’ve deployed to those data centers. We are moving, embracing in a big way public cloud architecture, whether that’s through AWS, whether that’s through GCP, or any of the number, any other number of cloud offerings.

    And so, as opposed to doing what some people would call a lift and shift where you just take your software that’s meant for, to be run on hardware that you own and move it into the cloud, we’re doing a fundamental re-architecture of the software to make use of all of the great things that cloud architecture allows us to take advantage of.

    Ashley: Mm-hmm. Fantastic. That’s interesting to hear a little bit about your own evolution at Salesforce. So, your talk is about using Spinnaker, you know, really about debugging and finding out problems that are happening in production, but sometimes you might struggle with trying to replicate it into a smaller environment to get the same problems working.

    Can you tell us a little bit about what sort of led you down this path to figure out how to do this? Was it a big problem that was happening or something you saw repeated over and over that there wasn’t a good solution to and you figured out how to do that? How did this come about?

    Lane: Yes. So, basically, as you’re taking workloads and migrating them over, I mean, when—you know, when you just start with a small subset of workloads, you know, the path is relatively straightforward. And, you know—hopefully, anyways—and you don’t run into too many issues that can’t kind of easily be solved.

    But the reality is, as you transfer more and more workloads over to the public cloud, that’s—you know, the devil’s in the details, right? So, that’s really where things can pop up where you’re hitting various limits or software isn’t performing in the way that you would expect it to perform. And these are the situations where we—where it can be very beneficial to jump into production software and really, you know, sometimes slap a debugger on it and see exactly what it is that it’s doing that differs from kinda what you expect. You know, and that can help you kinda tailor your workloads in such a way that you can make things run more smoothly.

    Ashley: Mm-hmm. I know sometimes using debuggers, enabling them—that can be helpful, but it also can be too much information, trying to sort through what all is happening, trying to find what should you be looking at. What are some of the challenges you’ve found by turning on debugging or using debuggers?

    Lane: Yeah. Well, so, I mean, there definitely is that problem that you’re saying just as far as too much information that’s coming out. One of the nice things about Spinnaker and the way the services are written is, you have a very fine grained tuning over which libraries inside of Spinnaker you tell it to print out and debug information.

    Ashley: Mm-hmm.

    Lane: So, if we know that there is a hiccup with one of the data binding layers or a hiccup with one of the authorization layers, then we can, through the config files, we can—and Java settings—we can really target that explicit directory, or I’m sorry, that explicit library and say, “Give me all the debug information that you have.”

    Ashley: Mm-hmm.

    Lane: But, you know, failing that, I mean, there are definitely times when it’s been advantageous and the best course of action is just to go down and actually look at the code and see what it’s doing. And, again there, it’s best to do that under—you can’t do it in production, usually, but what we can do is simulate a load that’s similar to what we would see in production and really, really take a look at what’s going on to help us identify those algorithms that might be o event squared instead of a login or something like that.

    Ashley: Mm-hmm. Now, are there some specific techniques—I know in your description of your talk, when you talked about using remote JVM debugging, custom profile builds, even using htop, you know, a UNIX command or a LINUX command to help you figure out what’s happening with multi-threaded microservices. It sounds like a variety of different approaches that you’ve kind uncovered and learned that you can use to figure out what’s happening.

    Lane: Yeah. And so, I mean, in general, we like to run as closely to the open source build as we can, the ones that are provided by Spinnaker, which is ultimately provided by Google. But there definitely are circumstances where we need an extra tool, be it htop, be it something like Glowroot, which is a Java application profiler where what we’ll do, then, is we’ll go in and we’ll build a custom image using the Spinnaker images as a base and then tack on those additional libraries and put them into the Spinnaker ecosystem and then launch them up just to see what additional information we can get out of there.

    And so, you know, one scenario where that was really useful to us, we ran into a scenario where cloud driver, which is—cloud driver is the main tool that talks back and forth to all of our different cloud infrastructures.

    Ashley: Mm-hmm, mm-hmm.

    Lane: Sometimes calls to cloud driver were taking upwards of, well, two to three minutes to respond. Now, you know, timeouts are set in such a way that if it doesn’t hear anything back in about 30 or 60 seconds, then it just disregards that load and, you know, so that created quite a bit of problems for us.

    By building a custom cloud driver image that had htop in it, we were able to see that the majority of the processes that were running were actually running basically commands to reach out to the Kubernetes clusters and get a list of all of the name spaces that are in the Kubernetes cluster. And, talking it over with some of the Spinnaker developers, what we found is that if you have 15 or so clusters that you’re connecting to Spinnaker, then that’s not so much of a problem to go and query each of those to get the list of name spaces. But as you scale up, on the order of 400 or 500 different clusters the way that we do, then a lot of the delays and a lot of your time can be just essentially Kubectl calls waiting to return to you the lists of name spaces that you need to go and scan.

    So, we implemented a workflow based solution for that, basically, where we let our teams know that when they’re creating their clusters, they should use Terraform to go ahead and create the clusters—I’m sorry, the name spaces that they’ll be using. And then, if they need to use a name space after the fact, then we provide a pipeline that they can use that will dynamically add in an additional name space that their cluster will start to scan. So, that saves us from scanning all the clusters all the time, which was causing quite a bit of performance bottlenecks.

    Ashley: Yeah, I would imagine that would have some overhead, maybe a lot of overhead if you’re doing that frequently. So, it sounds like a way to both reduce overhead, but also to get the information faster.

    Lane: Exactly, exactly—yep, yep.

    Ashley: Mm-hmm. Very cool. So, in your talk, are you going to be doing any demos? I know there’s always the demo Gremlin, or are you gonna be just showing, you know, talking about what some of these techniques are?

    Lane: So, I plan on doing some demos. As far as—

    Ashley: That’s really cool.

    Lane: Yeah. You know, I may do the, what’s the—the Easy Bake Oven a little bit as far as, “Here’s the behavior and here’s what we’ve found in code.” But from what I understand, a lot of that stuff can kinda be dependent on Internet connectivity at the actual site. So, if it’s something where we have good Internet connectivity, then by all means, I plan on walking through a couple of debugging scenarios, as close to what we would do in real time as possible.

    Ashley: Yep. Well, you know, someone somewhere—it’s been a while ago—gave me the great advice of, you know, “Have your live demo and have your disconnected demo ready in the background.” [Laughter] So, you can always at least show something locally if you can’t get on the net. So, if you’re depending upon the network—I’m not sure if you are for your demo, but always a good lesson, right?

    Lane: Sure, exactly.

    Ashley: Great. Are there any other kind of lessons learned, common mistakes, or mistakes that you or others might have made along the way, kinda so there’s hard things you learned by trial and error that you plan on sharing?

    Lane: I mean, well, there are—whew. You know, I’ve been working on Spinnaker for a couple of years. So, there’s definitely been a lot of hard lessons learned, here. But honestly, what I would do is, I would encourage anybody who wants to get into Spinnaker to not just hang around the Slack channel, because the Slack channel does have a tendency to get overrun with, you know, just kinda people posting their stack traces and just saying, “Hey, has anybody ever seen this before?”

    And, you know, I’ve gotten a lot more success by going through the commits, looking at the people who actually authored the code, and then reaching out to them directly with more than, “Hey, can you explain this to me?” but rather, you know, “Hey, I see what you did here and I see what you did here. I’m running into problems with these lines. Do you have a different approach, or is there something that I can be doing differently?”

    And the other thing that I just can’t overstate is the value of being a member of one of the special interest groups.

    Ashley: Hmm, interesting.

    Lane: So—yeah. So, I’m a member of the Kubernetes V2 special interest group that’s lead by Eric Semene and Ethan Rogers from Armory, Eric’s from Google. And it has, you know, it has been just an absolute wealth of information and, you know, honestly, I don’t know if we ever would’ve gotten nearly as far as we had without those two people.

    So, you know, yeah, I would just say that the community is really friendly and we always welcome new members who are ready to learn.

    Ashley: You know, I think both of those are great suggestions, and I really appreciate that you made those. Because, one, things like the Slack channels on projects, open source, those can be a bit intimidating. Sometimes they’re not approachable, because there’s just so much noise so much happening on it and people reaching out for help like you’ve talked about, “Here’s a stack trace I’m trying to figure out.”

    But also, your recommendation of reaching out to the code authors, you know what, it’s—people like to help each other. And, you know, it might seem like, “Hey, the people who wrote this aren’t gonna have time to bother with me”—they love to hear from people that are using their stuff to talk about it and help them out, but also hear about how they’re using it, and of course, they’re always looking for ideas and feedback and stuff like that. It sounds like you’ve had that kind of an experience.

    Lane: Yeah, absolutely. I mean, and you know, the big thing is just, you know, as a coder, it’s easy to tell the people who are coming to you and just kinda wanting you to fix it for them and the people that are coming to you that have really tried to tackle it themselves. And, you know, I can’t speak highly enough about the latter rather than the former. I mean, you know, just give it your best shot and when you get stuck, reach out to somebody and it’s, you know, it can be immensely valuable.

    Ashley: It’s kinda like going to a foreign country. Wherever you are, if you’re American going somewhere else or vice versa, everybody appreciates you trying to speak the native language, and at some point, when they see you struggle enough and how far you can go, they’re glad to help you and, you know, speak in your language.

    So, same kind of thing with helping people with code. If you’re gonna just fob your problem off onto the developer of it—not appreciated so much. But they appreciate that you tried to take it as far as you could. As you mentioned, go look at the code and figure out what’s going on.

    Lane: Yeah.

    Ashley: You’ll get immense respect, you know, even if you aren’t a coder at that level, at that level of software developer, it’ll mean a lot to the developers.

    Lane: Absolutely, absolutely.

    Ashley: Well, hey, I think you’re gonna have a fascinating talk, and I love that, you know, this idea of trying to figure out what’s happening in production and some of the techniques that you’ve come up with and developed and have experienced and the fact that you’re sharing those with others. I’m curious, do you contribute any code to the Spinnaker project in any areas? Are you primarily a practitioner user of it?

    Lane: So, I have. I’ve got a few small RPRs that have been pushed through, but really, the bulk of my commits right now have actually been to the Spinnaker website, the documentation. So, you know, I don’t know Java or Groovy or Kotlin, maybe, as well. Some of the patterns they use are a little bit—I come from a .net world, so they’re a little bit foreign to me.

    But yeah, I’ve definitely written a number of different documentation pages and I found that that’s a great way to kinda get in and I’ve even got some PRs that are coming ups soon that aren’t doc related. So, yeah, hopefully, you’ll see my name more.

    Ashley: Excellent. Well, you know what, documentation is important, too. There’s some folks doing talks at Spinnaker Summit that, you know, kinda ran into that point where, “Hey, there’s documentation for doing it one way, but not under this set of configurations or software.” So, that’s a contribution, too, so congratulations for being a part of the community and for sharing, also, your experience at the Summit.

    So, Chuck, appreciate you being on the podcast today.

    Lane: Oh, thank you. It’s been an absolute privilege. Thank you so much.

    Ashley: Absolutely. Fantastic. I wish you all the best with your talk, I’m sure it’ll be great, and hopefully folks listening to this podcast will draw some more interest and bring folks to listen to you.

    So, I’d like to thank our guest today, Chuck Lane. He’s lead software engineer at Salesforce.com, so you can imagine the environment he’s working in. There’s some super good lessons that Chuck’s bringing to the table. He’s gonna be talking at Spinnaker Summit 2019, which is in San Diego, November 15th through the 19th. His talk is debugging and profiling Spinnaker applications live, and his talk is on Saturday, November 16th at 3:45 p.m.

    I’d also to thank you—you, our listeners—for joining us today. This is Mitch Ashley with devopsy.kinsta.cloud. Have a great day and be careful out there.

    — Mitchell Ashley

  • The Accelerating Cloud Wars

    The Accelerating Cloud Wars

    Enterprises have embraced cloud computing at a phenomenal clip, according to newly-released report, A for Adoption, from cloud access security broker provider Bitglass.

    Over the past five years, the report found cloud penetration grew from 24% (in 2014) to 86% of organizations today. Last year, that adoption rate was 81%. Yet, while cloud has helped enterprises to reduce IT capital expenditures and become more agile in meeting business demands, these organizations need to be cognizant of the impact the shift to the cloud has on securing user access—something the report hints as an area where organizations lack.

    For instance, the Bitglass report found, of the 86% of organizations that adopted cloud, only 34% of those have implemented single sign-on (SSO). In addition to tracking SSO usage, Bitglass uncovered adoption rates for a host of different cloud-based tools, including Microsoft Office 365, Google’s G Suite, Amazon Web Services (AWS), Slack, Salesforce, Box and ServiceNow.

    The annual report highlighted the rapid increase in the adoption of a number of services, such as Salesforce and Slack, which respectively increased by 55% and 44%.

    The survey also found that Google’s G Suite, with a 33% adoption rate, is still struggling to regain headway on Microsoft Office 365 and that productivity suite’s 79% adoption rate. At 82%, financial services organizations are the fourth largest adopters of Office 365, while 79% of healthcare organizations have done so.

    Those enterprises that have deployed AWS increased by 43% in one year, reaching 20% adoption across all industries this year. Not surprisingly, the technology industry is the leading implementer of AWS at a 32% rate and is also the leading industry using Slack at 79%.

    One of the greatest challenges when it comes to effectively managing and securing access to the cloud is access management. Interestingly, only 34% of enterprises have implemented SSO for cloud access. However, the amount of SSO adoption varies significantly from industry to industry.

    For instance, the adoption of SSO in financial services grew nearly 41% year over year, while in healthcare that growth reached 30%. However, the technology industry hasn’t embraced SSO much more, having reached a 33% adoption rate. Interestingly, education led SSO adoption at 61%, with the government firmly in second with 46%.

    The adoption of SSO also varied by organizational size. As it turned out, larger organizations are the leading adopters of SSO. In fact, 64% of large firms said they utilize SSO, which is nearly 50% more than what medium-sized organizations reported. That’s more than twice the adoption of small organizations.

    The Bitglass report is based on the company’s scanned analysis of cloud to identify which cloud services were in use across a sample of more than 138,000 companies. According to the company, the analysis included productivity suites such as Office 365, G Suite and messaging apps such as Slack, as well as file-sharing apps such as Box.

    — George V. Hulme

  • Crossing the Ecosystem Boundaries: How ServiceNow, Salesforce and Atlassian Work Together

    Crossing the Ecosystem Boundaries: How ServiceNow, Salesforce and Atlassian Work Together

    Although these platforms were originally designed to serve different functional roles—Atlassian’s help desk, ServiceNow’s IT service management and Salesforces’ sales and CRM—from the outset, they all addressed the evolving mega-management and leadership issue: collaboration across teams and business units.

    Independent action, siloed organizations and disconnected thinking was increasingly giving way to more agile, interdependent, collaborative problem-solving practices and methodologies. Whether the differences were political, cultural, intellectual or institutional, survival became progressively dependent on living, working and communicating more effectively across all boarders. It was in our individual and collective, both internally and externally, best interest to do so.

    Effective companies and the platforms that served them needed to promote a culture that collaborated with less friction across five boundary types (“CCL’s” Center for Creative Leadership’s Boundary-Spanning Leadership)

    • Horizontal: Expertise, function, peers.
    • Vertical: Rank, class, seniority, authority, power.
    • Stakeholder: Partners, constituencies, value chain, communities.
    • Demographic: Gender, generation, nationality, culture, personality, ideology.
    • Geographic: Location, region, markets, distance.

    Collaboration initiatives generally begin by focusing on existing boundaries within a specific business unit or team. Then they expand to forge common ground on specific projects across teams, and finally, moved across all five boundary types with multiple teams and interdependent projects which some refer to as complex adaptive systems. These platforms were launched, quickly developed and continue to evolve to meet this collaboration challenge head on.

    Making Sense of the Blurring Boundaries Across Convergent Platform Roadmaps

    Boundaries are difficult to identify when they are continuously moving and being redefined. Instead of taking a more traditional route of seizing mind and market share by differentiating and establishing/defending clear boundaries, these platforms are doing the opposite, they are converging. The ecosystems that support each platform are also beginning to look increasingly similar—but more on this in a future post.

    The convergence of frameworks such as ITSM and Agile represents a tangential and interconnected set of moving boundaries intersecting somewhere along the spectrum at ITIL—ITIL4 if you’re counting. As all three platforms seek broader market penetration reflecting this full spectrum of frameworks, consider using the ITIL4 Edition’s 17 service management practices as a cheat-sheet for their boundary spanning enterprise roadmaps:

    • Business analysis.
    • Service catalog management.
    • Service design.
    • Service level management.
    • Availability management.
    • Capacity and performance management.
    • Service continuity management.
    • Monitoring and event management.
    • Service desk.
    • Incident management.
    • Service request management–includes both request fulfillment and access management of ITIL V3.
    • Problem management.
    • Release management–includes an explanation about releases in waterfall driven environments and DevOps driven organizations.
    • Change control–formerly known as change management.
    • Service validation and testing.
    • Service configuration management.
    • IT asset management.

    As organizations prioritize and re-prioritize the list reflecting their Agile/ITSM journey, the boundaries between platforms will move, and in many cases, simply disappear. As this journey plays out in your company, the platforms and ecosystems that support each will need be rationalized. Said differently, you may be asked or told to choose one, but as our experience suggests, you won’t need to do that today.

    Instead of diving into the technical features and benefits of each platform and ecosystem, take some time to reflect the benefits of expanding your boundaries to address the business challenges you are facing now and expect over the next 18 months.

    Where does this leave you and your team today?

    While everything else gets worked out….

    • Review the ITIL4 Edition’s 17 service management practices and rank prioritize for your team and company.
    • Do a self-assessment on your personal commitment to, and comfort with, the benefits of expanding your boundaries.
    • Meet with your team and have each of the individuals do the same.
    • Encourage conversations about where the platforms appear to be focusing (e.g., Atlassian focusing more on ITSM and ServiceNow paying more lip service to Agile).
    • When the time comes to make recommendations on app consolidation or choosing one platform over another, your team will be well prepared to do so with open, informed and agile minds.

    One last note on the benefits of expanding boundaries: Leaders who effectively reach beyond their present boundaries have the advantage when faced with solving problems, creating innovative solutions and evolving to thrive in today’s interdependent, complex world. The benefits of boundary spanning leadership include:

    • Increased organizational agility to respond to a dynamic marketplace.
    • Advanced cross-organizational innovation processes.
    • Achievement of mission-critical, bottom-line results:
      • An engaged and empowered workplace at all levels.
      • Flexible, cross-functional learning capabilities to solve problems and adapt to change.
      • Better-managed risks and rewards through enduring cross-sector partnerships.
      • Higher-performing virtual teams.
      • Global mindsets and cross-regional collaboration.

    Use these bullets to get your team spanning conversation started.

    — Joshua Platt

  • Report: More Salesforce Customers Adopting DevOps

    Report: More Salesforce Customers Adopting DevOps

    A survey of 201 executives who work in organizations that have adopted the Salesforce Lightning platform finds a surprising number are employing DevOps practices to customize Salesforce software-as-a-service (SaaS) applications.

    Conducted by Beagle Research Group on behalf of Copado, a provider of a commercial continuous integration/continuous delivery (CI/CD) platform for Salesforce SaaS environments, the survey finds 48% are using open source platforms to drive those DevOps processes, while 26% are relying primarily on in-house developed CI/CD toolchains. Another 36% are using commercial platforms developed for the Salesforce platform.

    Andrew Leigh, senior vice president of marketing for Copado, said DevOps has gained traction in Salesforce application environments because most digital business initiatives revolve around customer records and marketing applications. As organizations attempt to drive new digital customer experiences, they find they need to frequently update what have become highly customized SaaS applications.

    Many of those organizations are surprisingly agile. A quarter (25%) said they release code to their Salesforce production environment multiple times per day, while another 29% said they can implement changes in less than one day. More than half (53%), however, said deployment can take between a day and a week.

    Ambitions in terms of DevOps capabilities are running high. A total of 19% want to be able to deploy multiple times per day; while another 16% would like to release between once per hour and once per day. One-third (33%) want to able to at least be able to release customizations once per day to once per week.

    More than half, (54%) said their lead time for making changes to their Salesforce environment is between one day and a week. However, 21% said lead time is less than a day and 8% said they need less than an hour. Collectively, 83% said they can make changes in a week or less.

    Overall, 77% described their Salesforce DevOps strategy as being as mature as the DevOps strategies for other technologies in their companies. However, only 42% are consistently employing automation to drive DevOps processes.

    Like most organizations that have adopted DevOps, it doesn’t appear customers who rely on Salesforce are immune from their share of DevOps issues. Almost half (43%) said they have performance problems after a deployment up to 15% of the time. Only 2% said they had issues between 76% and 100% of the time. One-fifth (21%) said the time to restore service levels is less than an hour, while 43% said it could take up to a day to rectify an issue.

    As far as future plans are concerned, the top three priorities identified by survey participants are increased speed to market and increased developer productivity (tied for first place), making applications more customer-relevant and continued innovation (tied for second place) and increased employee satisfaction and release quality (tied for third place).

    Salesforce may not be getting its full due for being a provider of a SaaS platform for building customized applications. However, it is clear that most Salesforce customers have come to recognize that SaaS applications are just another type of platform for building and deploying customized applications using best DevOps processes.

    — Mike Vizard

  • ICE Controversy May Lead to IT Contract Chaos

    ICE Controversy May Lead to IT Contract Chaos

    For as long as most IT professionals remember, the only political issues any IT organization considered were largely internal. However, that appears to have changed in 2019 as more IT professionals begin to question whether they want to do business with IT vendors that support an organization they staunchly oppose on moral grounds.

    This week that very drama is playing out in the form of a reversal after Chef CEO Barry Christ announced the provider of IT automation software would no longer provide support for its software to the Immigration and Customs Enforcement (ICE) agency, which is enforcing immigration policies enacted by the Trump administration.

    The issue came to a head when Seth Vargo, a contributor to the open source Chef repository, decided to remove what many consider to be a critical module of code he contributed to the community to protest a support contract Chef had in place with ICE. Late last week, Christ said Chef would continue to support ICE; however, bowing to what he described as internal employee pressure, he reversed that decision earlier this week.

    It’s not clear what impact this move will have on ICE. After all, there are many service providers that ICE could turn to for support. The decision, however, may open a Pandora’s Box, given all the stances IT professionals might take across the political spectrum, said Judith Hurwitz, principal analyst for the IT consulting firm Hurwitz & Associates.

    Whether it’s gun control or conflicts in the Middle East, the potential for IT chaos is high if organizations have to consider a range of potential blowback if they have to consider how employees and potential customers might react, Hurwitz noted.

    In many cases, software companies make their software available online, which makes it exceedingly difficult for them to know who is using it when it was paid for using a credit card, she said. In other cases, no one can prevent anyone from downloading software that has been made available via an open source repository.

    “I’m not sure you can sell software based on who is going to use it,” Hurwitz said. “It’s going to get complicated.”

    The controversy surrounding ICE is likely to escalate further. Last August, protesters disrupted an Amazon Web Services (AWS) to vocally express their displeasure with the company’s decision to provide cloud services to ICE. Last year, Salesforce had to contend with an internal employee revolt over a contract the company has signed with U.S. Customs and Border Control Protection. Salesforce wound up donating $1 million to help families affected by U.S. immigration policies. Chef CEO Christ, in his memo, appears to be following a similar course in involving an ICE contract valued at $95,000 that has been in place since 2015.

    It’s not clear to what degree political passions will influence future IT contracts, but it is clear that organizations need to proceed with care. There are likely to be just as many individuals within an organization on one side of an issue as another. Most organizations these days can’t afford to lose key members of the IT staff over moral and political arguments. The trouble is, fewer IT people seem inclined to agree or disagree in the name of maintaining corporate neutrality.

    — Mike Vizard

  • Acquisitions to Fuel Programmable Analytics

    Acquisitions to Fuel Programmable Analytics

    Now that Tableau Software has agreed to be acquired by Salesforce and Looker is set to become a part of Google, the rate at which analytics will be embedded within almost every application is about to accelerate.

    Tableau today is relied on by more than 86,000 organizations to surface business intelligence via data visualizations created by professional analysts and line of business executives. That user base accounts for why Salesforce is willing to spend $15.7 billion to acquire Tableau.

    Competition within the analytics software space, however, has always been fierce. The rise of the cloud has resulted in several analytics startups challenging incumbents for a piece of one of the fastest growing sectors of the enterprise software market. One of those startups is Looker, which created a cloud-based analytics platform that Google is now set to acquire for $2.6 billion.

    Google has already signaled its intent to make Looker a part of its expanding Google Cloud Platform (GCP). As such, Google Cloud CEO Thomas Kurian last week noted one of the primary reasons for the Looker acquisition is to add a software-as-a-service (SaaS) offering that will enable developers to embed analytics within their applications by invoking a set of application programming interfaces (APIs) exposed via a cloud service. Today that analytics service runs on GCP alongside the Google BiqQuery data warehouse. Google, however, has also signaled its intent to make Looker available on multiple clouds alongside the rest of its software portfolio.

    Tableau, which will continue to operate as an independent arm of Salesforce, is playing catch up in the cloud. Tableau is deployed widely in both on-premises and public cloud computing platforms, including as a managed service provided by Tableau through which the company manages a dedicated instance of its software on behalf of customers. The merger with Salesforce will create an opportunity for Tableau to add a full software-as-a-service (SaaS) application instance to its portfolio that leverages the same infrastructure that Salesforce employs to deliver customer relationship management (CRM), marketing and customer service applications. Salesforce CEO Mark Benioff this week said going forward, Salesforce fully expects analytics generated by Tableau to drive a raft of digital business transformation initiatives.

    Most of the analytics that will be embedded within applications will manifest themselves in three forms. The first is embedded software that will be updated continuously as new data is entered in an application. The second is embedded predictive analytics modules that will invoke big data repositories and machine learning algorithms to surface recommendations on how to optimize a business process or customer experience. The third—and more ambitious—goal is an embedded prescriptive analytics capability that automatically optimizes business processes and customer experiences in real time based on events occurring, for example, within an internet of things (IoT) application.

    Every provider of analytics capabilities, from traditional Tableau rivals such as Qlik Software and Microsoft to TIBCO Software, IBM, MicroStrategy, SAP, Oracle and host of others, is pursuing all these emerging use cases for programmatic analytics. Most recently, Information Builders revealed it has embraced Docker containers and Kafka messaging platform as a means for achieving that analytics goal.

    The arrival of programmable analytics platforms will, of course, make implementing best DevOps practices all the more challenging. It’s hard to think of a business process that will not benefit to some degree from embedded analytics. The challenge DevOps teams will face is embedding and then continuously updating all the analytics modules embedded within the applications they deploy. The good news is that as organizations move to embed analytics everywhere increases, so too does the need to embrace DevOps to manage it all.

    — Mike Vizard

  • 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