Categories
Tips

Working in corporate to founding a developer first company

Last month I got a chance to sit and talk with Darshan Shivashankar, founder and CEO of APIWiz on our brand new podcast. We two have collaborated in the past on API lifecycle management workshop and Darshan being a technical founder, whenever we talk our conversations tend to go in all places technical. So catch up on everything we discussed in this 50 minutes episode but here’s a quick summary or gist if you will for someone who needs more buy in before lending the episode their ears.

Darshan has 15+ years of experience in industry building technical solutions especially when it comes to designing API programs for companies looking for Digital transformation. In the past Darshan has worked with various industries from telecom to healthcare, FinTech to Neo banks. Though now a founder of developer first company, Darshan shared he never envisioned or planned his career to follow a fixed trajectory. Opportunities started coming in as he worked on more advanced projects and with right problem solving mindset and experience, he was acing the digital transformation process of the industries he worked in, sometimes leading and even starting their API first journey. 

Darshan figured out the technical debt associated with APIs journey of organisations wherein teams work in Silos, leading to a lack in collaboration, reliability and consistency in governance. If you’ve worked in APIs development for a big project or digital transformation mission, then you could easily relate to it. This is where Darshan felt a need for a solution that could help in API lifecycle management. After validating this idea within his network he realised that indeed there is a requirement for such a solution but not an immediate urgency to have that in place. This gave Darshan and team the opportunity to bootstrap their journey building APIWiz, focusing on addressing Developer centric problems.

I asked Darshan if he’s still involved in the development of the product and he mentioned he was actually writing code till very recently but now he’s more involved in hiring, planning and giving direction to the product, though he still knows the codebase in and out and is always ready to pull up his sleeve and get down to programming and tracking bugs whenever required, which for me was really inspiring to listen. The team at APIWiz is now scaled up after they raised funds from their investors and that’s where Darshan focused on hiring the candidate with right vision and mindset, as he believes tools and skills can be learned at job but problem solving attitude can’t be taught. Darshan also mentioned motivating team members to fill the job roles needed within the organisation enabling them to explore more arenas to work and fit in. 

I also asked Darshan where he sees industry heading and things he’s most excited about but I’m gonna tease, as he really has a deep and interesting perspective on this one which I feel you should listen straight from the Podcast to better understand it. 

P.S : eBPF and Raspberry Pis were mentioned 😛

Darshan also shared the struggles associated with starting a company from scratch, the role of support from family members, friends and people within your network and great tips for anyone just starting out fresh in tech and wanna make big, making this one of my favourite episodes.

If you listen to it don’t forget to share it with your friends who might learn a thing or two from this podcast. As always I’m always looking forward to your feedback to make this podcast better and if you have any guest suggestions feel free to share it via the comment section below.

Categories
Community Tips

Protecting APIs by Merging Tools and Security Best Practices

Rapid uptake in adoption by industries ranging from banking to retail to autonomous vehicles of customer- and partner-facing and internal application programming interfaces (APIs) to drive internet traffic has resulted in an equally rapid growth in endpoint attacks – more than 11 billion over just 18 months according to a report from edge computing security leader Akamai. It makes sense that they are more vulnerable to threats from malicious actors, given API endpoints’ similarity to internet-facing web servers, and their role as pipelines between divergent platforms.

For DevSecOps teams, protecting APIs is a top priority; they are vital to mobile, SaaS, and web applications and paramount to a healthy software development lifecycle. API security is also a natural extension of DevSecOps’ push to break down silos between development, security, and operations and move toward automation and design that integrates security as a shared responsibility. 

Thus, it is time to view API security not as an external bottleneck, but as a part of a stable long-term strategy. This can be achieved by altering company attitudes and investing in API tools that facilitate testing, enforce governance standards, and automate recurring security tasks.

Adopt an API-as-a-Product Strategy

A primary reason digital transformation efforts have failed for many brands is because they do not see APIs adding value. As such, they’ve lost track of the potential return on investment (ROI) APIs can deliver. When APIs are not viewed as assets or value-generating, they aren’t subject to the appropriate level of protection or security performance oversight. In fact, Akamai’s report highlighted the fact that many enterprises relegate API security checks to the end of the lifecycle and rely on traditional network security solutions which aren’t designed to protect against the attacks to which APIs are subject.

This is starting to change, however, as API-as-a-Product strategies gain traction within the developer community. There is a notable shift away from delivering project features based on budgets and deadlines to holistically examining APIs as products and assessing their capabilities. Further, as the concept of monetizing APIs gains prominence, their protection becomes a higher priority at the outset, with organizations more inclined to adopt a human-centered design approach. 

What this means is moving API regression tests to the forefront rather than treating them as an afterthought. It means adopting a design-first approach – wherein everyone on the team speaks the same language and every tool is able to leverage the same design – from the outset with the help of an API management platform. This will also help ensure that APIs are built on established authentication and authorization mechanisms such OAuth 2.0, which is the industry-standard protocol for authorization, and OpenID Connect.

API testing tools are critical for protecting something upon which most services in use daily rely. These tools let developers see if an API is reacting adequately to unexpected inputs or possible security attacks. They show immediately if an application is running with optimized functionality, reliability, and security.

Whether it is running user authentication, parameter tampering, unhandled HTTP, or fuzz testing, it is imperative to test an API contract to ensure that services can communicate and that the data they share is consistent with a specified set of rules or standards. Further, there are many solutions in the API testing market, including cross-cloud API testing software, software that supports asynchronous testing and continuous integration/continuous deployment (CI/CD) integrations, and end-to-end testing – as well as solutions that support various formats eliminating the need for developers to learn new languages. 

Continuous testing is essential across the DevSecOps pipeline, as is robust test coverage based on API contracts that have been designed and approved. Plus, by chaining together complex API transactions and workflows, cases can be tested on-demand using continuous delivery or CI/CD to reduce downtime. 

Security in 360-degree Lifecycle Management

While API security considerations have typically been an afterthought to ever-increasing business demands, the reality is that no enterprise can afford for software security checks to be the last stage of an API lifecycle. Rather, security must be part of a 360-degree API lifecycle management strategy. It should be incorporated into every level, from planning and design to developing, testing, and release management – all the way out to deprecation.

Developers must also have oversight throughout the entire API lifecycle – which is where an API management platform comes into play. A dedicated platform can provide workflow visualizers that show an API’s complete lifecycle in a single view with issue alerts, which helps accelerate production using CI/CD in the DevSecOps pipeline to build trusted artifacts and more rapid iterations, thereby guaranteeing a security-first mindset. 

API tools also allow perimeter scans, which enable the discovery and inventory of APIs and allow for easy breakdowns for DevSecOps teams to work with. The best platforms will leverage a command line interface (CLI) – a unified tool for managing and controlling multiple services from the command line or with automation through scripts – to make APIs more easily discoverable. The team can easily determine where and how many APIs are deployed; a level of visibility that is mandatory for enterprises. 

Tools for Success

In short, an API team is only as successful as the set of tools at its disposal.

API security best practices are no mystery to seasoned security professionals – and they start with establishing solid API security policies through an API management platform. 

Finally, a collaborative approach to API governance – in line with the DevSecOps mission to eliminate siloes – is imperative for any organization’s security. 

About APIWizAPIwiz is a low-code, API automation platform allowing developers to build and release reliable APIs quickly. With APIwiz, API teams have complete control, visibility, and predictability over their entire API program, allowing organizations to stay open and connected.

Categories
Business Platforms

Microsoft’s Mobile Opportunity

Microsoft was slow to react to the step change in user experience provided by iOS and Android versus the first generation smartphone platforms. Windows Phone was then late to market and has finished a distant third in the smartphone platform wars. Smartphone adoption was consumer led and in the race to catch up Windows Phone skipped some enterprise friendly features. This has left it out of the running for business adoption too. In tablets, Windows RT was largely rejected by the market and Intel processor based devices running Windows 8 have only managed a weak third place in the market so far. In terms of their share of the mobile OS market, Microsoft is a long way behind Apple and Google. However, as enterprises are increasingly making big investments in mobile, Microsoft’s mobile opportunity is still not lost.

infragistics-2-cover

If you can’t beat them, join them

Microsoft’s new CEO, Satya Nadella, has made it clear. The company’s focus is now mobile-first and cloud-first. This includes aggressively rolling out their services across iOS and Android.

In fact they already have more than 100 apps across the two platforms and that number is growing fast. Nadella has not been hesitant to acquire technology where previous strategy has left gaps. The new Outlook apps for iOS and Android is based on the Acompli apps that Microsoft acquired late last year. It will likely be enhanced in the near future with the technology from recently acquired calendar app Sunrise.

In addition to filling out their offering and buying in talent for their competitors platforms, they have also moved to protect their dominance in productivity software. Microsoft Office is free for consumers on mobile platforms. To sweeten the deal for those who pay they’ve added unlimited storage via OneDrive. They then removed reasons to switch by opening up to competing storage solutions such as Dropbox and Box.

Following the old adage that the best form of defense is a good offense, these moves help keep Microsoft’s central position in the daily life of business users whilst starving startups hoping to topple them of revenue. No-one without Microsoft’s scale can compete directly on price whilst offering similar value.

Developers, developers, developers!

The other key to protecting Microsoft’s core enterprise revenues is keeping their technology stack at the heart of enterprise app development. For this to happen, third party enterprise app developers need to stick with .NET and related tools to build apps for iOS and Android. Developer loyalty is where Microsoft has been very strong.

Slashdata’s Developer Economics surveys repeatedly show Windows Phone with massively higher developer mindshare than the installed base of devices merits. That mindshare also continues to grow despite ongoing lack of traction with device sales.

One of the reasons for this developer loyalty is that Microsoft makes top class developer tools. They’ve invested heavily in this area for a very long time. Most developers don’t want to downgrade their tools and productivity in order to target another platform.

While Microsoft didn’t do the groundwork necessary to let developers target iOS and Android with their tools, Xamarin did. Microsoft and Xamarin have a global partnership to enable C# developers (and to some extent Visual Basic developers) to target iOS and Android via Visual Studio. Microsoft open sourced their state-of-the-art Roslyn compiler technology for .NET, presumably mainly so that Xamarin could integrate it. It seems likely that the partnership between the two companies will deepen at some point, probably through investment or acquisition. In any case, it seems to be working.

In the Q1 2015 Developer Economics survey, Xamarin was the second most popular cross-platform tool, behind only PhoneGap/Cordova.

The survey data also shows that C# is clearly on the rise as a language for mobile development.

Microsoft’s Mobile Opportunity: The next best thing

If you can’t own the OS and platform APIs then the next best thing is to own the developer tooling and thus the key relationship with developers. If you want to introduce or drive new features or standards (that don’t require new hardware or OS level support) then it’s the developer relationship you need to own rather than the platform itself.

Arguably a lot of innovation in mobile going forward will be achieved through cloud services. Microsoft would love to own those APIs. This only goes so far in the consumer space. Apple and Google can veto Microsoft’s moves at the public app store interface. However, in the enterprise, where most apps are not distributed via the public app stores, anything goes. This is where Microsoft’s biggest mobile opportunity lies. It’s also where the bulk of the revenue in app development will end up.

If Microsoft can keep a huge pool of developers fed and happy on mobile then they’ll be in a much better position for whatever comes next in computing.

Categories
APIs

Device API Usage and Trends

In the early stages of new technology markets, a lot of services are created because new technology has made new ways of doing things possible. [tweetable]Where app developers go, apps and then users will follow[/tweetable]. By looking at the popularity of various device APIs across platforms, we can see which developers are making the most of the capabilities their devices offer. If we then look at the device APIs that developers say they plan to adopt, we can see future trends in the app market, possibly months before the apps start to appear. Would it be wise to move against the herd, or is the trend really your friend?

Distinctively mobile computing

Mobile computing devices enable a greater range of applications than their desktop counterparts purely by being mobile. There are also features that are unique to, or much more relevant on mobile devices. In our last survey we asked developers about their plans for and usage of device APIs related to these features to gauge how much different groups of developers are taking advantage of mobility. The device APIs we asked about in our survey were those available to HTML5 developers, which allows us to compare their usage versus native developers across the most popular platforms.

Rather unsurprisingly, it turns out that HTML5 developers make less use of almost all device APIs than native developers. A lot of web developers are targeting desktop as well as mobile platforms and as such are less likely to build functionality that relies on mobile device specific APIs. However, that does seem to be changing as HTML5 developers are among the most likely to say they’re planning to use the majority of device APIs. You can see the popularity of each of the APIs covered in our survey by primary platform in the interactive chart below.

Another point to note about almost all of the APIs surveyed is that a greater proportion of iOS and Android developers use them than for other platforms. This suggests some maturity factor for platforms, either through increased competition causing developers to seek out more mobile-specific niches, or more likely, developers becoming more creative with ways to enhance their apps with mobile features over time.

Peering into the future

The differences between what developers are currently using and what they plan to use allows us a glimpse at future trends. Some of them are obvious, like the increase in intent to use the video camera. Video has long been more engaging for users but making effective use of local capturing and uploading relies on high bandwidth mobile uploads, which 4G connections provide. This trend is already preceded by mainstream services like Twitter’s Vine and video features for Instagram and Pinterest. For web developers, WebRTC offers the promise of easily integrated video chat in any site.

Voice recognition is another area where the trend is expected. The technology is maturing and the platform providers are investing heavily. It’s interesting that Windows Phone has the highest fraction of current usage here and the highest planned usage by a fairly wide margin. Perhaps there is some very effective developer marketing for the relevant APIs going on here?

Other APIs on the rise are less obvious, particularly the increase in interest in proximity sensors – the sensor normally used to detect whether you’ve got the phone held to your ear! It’ll be interesting to see what other creative uses developers put this to, or if it has been mistaken for technologies like NFC and Apple’s iBeacons. Sharing and Pairing is another less obvious candidate – as we didn’t specify exact technology here, it’s safe to say interest in various forms of social sharing from apps is unlikely to decline anytime soon and local sharing options such as Apple’s new AirDrop feature are likely to be popular.

User needs trump technical possibility

Given that Apple and Google (Motorola) have added special hardware for motion sensing, it’s not surprising that there’s a resurgence of interest in this type of API. Lets hope this time we get more creative uses like Magic Plan and not just a lot more motion controlled games and fitness trackers. For those looking where to take their app business, it might not be wise to follow any of these trends. Where lots of developers are exploring (and we do all love to explore new technology) there will be a lot of competition, yet the more general transition to mobile computing is still in the early stages. There are probably much more lucrative opportunities in slightly less exciting corners of the market.