As you bear down on Kubernetes security, use these strategies to avoid missteps in work with containers and orchestration
Why CTOs must design for developers right from the start
In today's integrated world, no software can stand on its own. So CTOs need to create APIs right from the start — and consider developers as they would end users. That advice comes from Uri Sarid, CTO at MuleSoft, which helps organizations connect data, applications, and devices. In this interview, he shares his thoughts on the importance of interoperability.
The Enterprisers Project (TEP): CTOs are much more aware these days that their technology won't stand on its own. Does this mean they need to think about interoperability right from the get-go?
Sarid: CTOs need to design for interoperability at every stage. Right from the start, you need to think about services you can tap and opportunities you can give outside developers. Uber is a great example. Rather than develop their own payments system, they used a third-party API. In turn, they developed their own API for third-party mobile apps like Transit. The API expanded the value of the apps, and the apps sent more business to Uber. Both sides benefited.
TEP: What kinds of mistakes lead to software that doesn't play well with others? What do CTOs need to stay aware of and what other roles (such as CMO?) do they need to get involved when creating new technologies or products?
Sarid: To 'play well with others,' you need to clearly define which tasks your software will handle, and which you'll give to third parties. You don't want any confusion about your system of record for payments, for example. Do you hold the credit card info or does your vendor? Any glitches will affect your customer relationships, which is all the more reason to make build vs. buy decisions early and work closely with the CMO and the rest of the executive team.
TEP: You've talked about the need to create software that meets needs you can't anticipate. How can CTOs do this?
Sarid: It's all about planning for the unexpected. First, build less. Drop features that aren't absolutely necessary. The less bloat, the less you'll need to change as your user's needs evolve. Strip your product down so it feels uncomfortably lean. That's a good sign you're on the right track.
Next you need to make sure others can extend and embed your product on their own. Self-service is key. The art is striking the right balance between developing features yourself and giving others an opportunity to build on what you've created. When you do it right, everyone profits.
TEP: What are some of the best ways to make your software developer friendly? And how do you make sure to get on developers' radar so that they will use your APIs?
Sarid: First, developers seek out examples. They don't read marketing blurbs. They don't read docs. They don't read specs. Or rather, they read them if they have to, as reference material. But what they love to start from are examples. Developers are pattern recognizers. They're "programmed" to infer the overall capabilities of your offering from examples of how it's used, to infer how to accomplish a task by seeing related examples, to infer API syntax specifications from example API requests and responses.
So put time and effort into building great examples that are known to work. Give them a wide variety of tools to get started, and reduce friction as much as possible. Minimize downloads and provide interactive tools to try things out. Generate SDKs to help developers call your APIs correctly. Explain error conditions as well as success conditions. It's all too common to concentrate on the "happy path." And make sure you thoroughly test your APIs so they actually work the way you claim! If your APIs delight developers and make them successful, they'll tell their friends and followers. After all, the best way to get on developers' radars is through word of mouth, amplified by the Internet via blog posts, forums, ratings, reviews and Github projects.
TEP: Finally, any advice for CTOs for thriving in today's fast changing world?
Sarid: Know when to go with the flow and when to buck the trend. As a CTO, you need to know what the trends are, what the 'smart money' is placing bets on, what's dying, what's exploding, what technologies will attract the best developers, and which they're avoiding like the plague. Sometimes you'll see that everyone has started using some continuous integration stack or containerization technology or new development tools, and you're using something else. Ask yourself if maybe they're on to something. If so, figure out how to benefit from their experience. But also know when to stand your ground. Maybe everyone is doing things in a needlessly complicated way and you see a better approach. Or maybe you've cracked a hard problem in your core competency. That's your differentiator. Lean into it.
- How DevOps ended finger-pointing in this Argentinean government agency
- 3 trends making CIOs' jobs even more complex
- Ask business leaders to present to IT
Uri Sarid is the CTO of MuleSoft. Uri brings over 20 years of technology and research leadership experience to MuleSoft, most recently as Vice President of the NOOK Cloud at Barnes & Noble, where he architected, led, and released the flagship digital content and user platform for NOOK. Previously, Uri was VP of Engineering at eMeter (acquired by Siemens), the leading provider of enterprise software for the SmartGrid. Uri has also held CTO and VP of Engineering positions at innovative companies including Loyalize, Aptana, Accomplice, Noosh, and digiGroups. Uri began his career with research and teaching positions at Stanford University, Lawrence Berkeley Lab, and the University of Notre Dame. Uri holds a Ph.D. in Theoretical Physics and Astrophysics from Harvard University and a B.S. with Highest Distinction from the University of Arizona. He is an author on 7 patents.