Dimitri Sirota

Dimitri Sirota

Dimitri Sirota is an accomplished entrepreneur and a pioneer in the security field. Prior to co-founding Layer 7 Technologies, Dimitri co-created the award-winning Virtual Private Network provider eTunnels Inc. Dimitri spearheaded its early marketing and business development activities, establishing eTunnels as a leader in secure connectivity for the extended enterprise. He has also worked in senior product marketing and channel development roles at AT&T and Telus. Dimitri holds a Bachelor of Science degree in Physics from McGill University and a Master of Science in Engineering Physics from the University of British Columbia.

April 3rd, 2013

Getting Perspective on Your Big Data

Data LensAs we see it here at Layer 7, there are two big problems with Big Data:

1. There’s just so much of it that it’s easy to lose sight of the byte-sized trees in the petabyte-sized forest

2. It’s locked away in every recess of the enterprise – from applications to relational databases, to non-relational databases, to in-memory caches, public clouds, Hadoop clusters etc.

Data growth and diversity have made data access harder. But data access is the foundation of mobile app development, anything to do with the Internet of Things (IoT) and all kinds of Big Data analytics. Given this need for data in the face of access complexity, it didn’t come as a total surprise to see some of the most innovative Layer 7 customers start using our API Gateway technology as a novel data access, aggregation and presentation solution. As our resident IoT expert Holger Reinhardt pointed out to me: they are using our products to build highly-customized “lenses” across their distributed data backends. To me, this characterization is perfect because what these customers are looking for is perspective on their data. A lens gives perspective with focus.

Now, a Layer 7 API Gateway is more than just a data integration solution. Our technology has several unique features that make it ideal for collecting, composing and presenting data. First, we can talk to all kinds of data sources natively. That wasn’t easy to achieve and it’s something we developed over many years. Second, we can represent the source data as a RESTful API. Even better, we can dynamically generate a virtual API view for a specific user, app, partner etc. The API then becomes the entry point for accessing the aggregated data. Third, we can add fine-grained access and protection policies that ensure only authorized consumers get visibility to specific slices of data, while also protecting the data sources from attack and misuse. When combined, these capabilities give organizations a way to focus on just the information that is relevant to a particular mobile, IoT or Big Data analytics project and then share selectively with an app, cloud service, developer or partner.

A data lens is born!

If you want to learn more about our Data Lens solution, have a read of this new solution brief. Also, feel free to reach out to us with any questions.

April 1st, 2013

Apigee Announced an API Exchange Friday – Somewhere a UN Agency Shed a Tear

Written by
 

Apigee API ExchangeA decade ago, during the first wave of Internet innovation, countless business plans began with the breathless promise of becoming the UN of this or that information exchange. ECommerce and communications would be transformed through the mediation of a neutral “man in the middle”. Here’s what happened: the communitarian exchanges failed; businesses that went direct to consumers succeeded; the hope for communal mediation was left to overreaching consortia grasping after fading relevance.

Why did  the “disintermediated” direct-to-buyer model win? Simple: it was simplicity. The problem with multilateral exchanges is complexity. They require members to buy in completely and never hedge with alternative paths to consumers; they require the exchanges to always be subservient to the members; and they require 100% participation and 100% consensus. That’s why they keep failing despite the best efforts of organizations like GSMA, the UN, OASIS and others. They require a rigid web of multilateral agreements, subjugation of individual corporate needs to ephemeral collective goals and universality. Just because the broker is a for-profit entity like Apigee doesn’t change anything so long as success or failure depends on universal cooperation and comity. To repeat an oft-used metaphor: putting lipstick on failed efforts like WAC and OneAPI won’t make them any more attractive. They will never have the agility and directness of an over-the-top direct-to-buyer/consumer/developer service. That’s why giant operators keep getting beat by three-person Y Combinator start-ups.

Does this mean aggregation is dead? Of course not! Aggregation models can work but only if the “broker” has the independence and freedom to go off and negotiate unilateral agreements as needed. The aggregator must have the freedom to be run like a self-interested business where the wishes and hopes of the underlying providers don’t factor in. As evidence look at the growing disparity between Netflix and Hulu. The latter emerged as a deliberately-crippled response to the growing power of Netflix. However, the need to accommodate multilateral interests has made it irrelevant. ISIS is fairing no better in the payments arena.

For operators, there is a similar lesson. Be the broker or sell to the broker. Each model has clear economics and places success or failure in the hands of the operator. If an operator wants to offer non-geo-specific services to buyers, it should partner with over-the-top providers or get the capacity from other operators one-to-one. If an operator would rather wholesale its services, be promiscuous and enable every broker/aggregator to consume its services, fine. Then let them be your buyers. The beauty of both models is that they are non-exclusive and don’t require consensus, universality or other impracticalities.

I give Apigee credit, the API Exchange is an improvement over the failed WAC. However the problem was never just technology. Some business models just don’t work in practice.

March 28th, 2013

Who Owns Your Developers?

Developer CommunityFor API publishers, acquiring developers is a pretty fundamental matter. “More developers, more money and reach” goes the thinking. But are all developers of equal value? And is borrowing a developer as good as true developer ownership?

My rather unsurprising answer to both questions is: “No”. Clearly, some developers will be more valuable than others and borrowing will never be a substitute for ownership. Here’s why:
•    The only developers that matter are those that are engaged and active

Registration numbers don’t matter. “Key Wielding” this or that is marketing fluff. Looky-loo’s don’t build apps that drive revenue or reach. They may take your time, they may toy with your APIs but they won’t deliver business value. And if they are borrowed, “drive-by” developers, guess what – they never will!

As a vendor that helps organizations publish APIs, my advice is to always own your developer. Don’t get caught up in the promises of vendors lending access to hordes of faceless developers. The only developers that matter are the ones engaged directly with you because those are the ones that care about your API and those are the ones that you can develop and nurture.

This does not mean that making it easy for high-value developers to access your APIs should not be a goal. Giving engaged GitHub developers the ability to use their credentials to access your APIs is smart. There are millions of current, high-quality developers waiting for the right project.

So, pick a vendor like Layer 7 that enables onboarding and Single Sign-On from GitHub and other deep pools of active, engaged developers. And be careful not to get caught up in the developer equivalent of a feel-good payday loan. You will pay a high price in the long run.

October 12th, 2012

Dispatches from NY
Don’t be a Control Freak

Interop New YorkA week back, I had the privilege of joining some industry peers at New York’s Interop conference, to discuss trends in enterprise mobility. Each of the companies represented a sub-segment of the mobility space. We had a big data company, an MDM vendor, a client virtualization company and me representing the MBaaS wing. Each presenter made a case for why their sub-segment is essential to enabling the mobile enterprise.

Not surprisingly, they all emphasized their security and management credentials as being central to their value propositions. Each vendor took a different approach to protecting the welfare of the enterprise but in the end, we all promised we could defend organizations against risk, both technological and financial. What we neglected to mention, I realized afterwards, was that a little risk is sometimes good.

Don’t get me wrong, security is something I take seriously. We at Layer 7 guard some of the most sensitive government and commercial APIs against cyber attack and misuse. But there is a downside to an unbalanced emphasis on insecurity – and that is fear. Some fear ensures prudence. Too much fear can arrest the progress of whole industries.

In a few short years, smart mobile devices have completely transformed how we communicate, socialize, shop and get entertained. Almost overnight, an economy has grown up around mobile apps. This same app explosion is poised to change how enterprises function, by completely un-tethering employees, while providing a way for companies to reach their customers beyond the PC and TV. But to get there, enterprises will have to encourage app innovation and the only way to achieve that is by opening up.

Now, no one says that opening up needs to be a foolhardy effort. Opening up data and applications to mobile apps needs to be done in a guarded and prudent manner. But in all the talk around mobile security, it’s important not to stifle innovation around mobile development. Security has to go hand-in-hand with connectivity.

October 11th, 2012

Open up to the App Economy: API Management as a Service

APIfy LogoApps are everywhere. We are surrounded by them. They’re overrunning our smartphones and forcing us to buy ever larger tablets. They are on our TVs, on our game consoles, on our set-top boxes – everywhere in our living rooms. When I update my vehicle, I expect I’ll be asking what version of Android my prospective car has before I ask about its engine configuration.

Apps have become ubiquitous in just a few short years. It’s no surprise, then, that companies large and small want to be part of the app economy. For these companies, enabling internal and external app developers holds the promise of growing market reach, opening revenue streams and maximizing customer retention – all on the back of developer innovation.

For almost a decade, Layer 7 has been helping large organizations open their data and applications to outside partners, cloud services and developer communities. With APIfy, Layer 7 is now making these same capabilities available to smaller organizations and departments, straight from the cloud.

To small organizations looking to open their first APIs to outside developer communities, APIfy offers the core API Management, security and community features necessary to get started. And for users that end up wanting more advanced features, APIfy provides an easy entry point to the Layer 7 API Management Suite. With APIfy, we aim to create an API platform that can grow with our customers.

Over the next several months, we’ll be offering APIfy free on a limited-use beta program. We’re eager to get feedback, so we’re inviting you to sign up and work with us to make APIfy an industry-leading service for opening APIs to the app economy. Enjoy the trial and let us know how we can make things better!