Author

I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)

Meta
Tags

Tuesday
Oct212014

## How we ended up writing our own programming language

About one year ago, my company had the opportunity to expand into an area which was very new for us at the time : pricing optimization for commerce. Pricing optimization is quite different to demand forecasting; the latter being the original focus of Lokad at the beginning of the company’s existence. While demand forecasting fits rather nicely into quantitative frameworks that allow you to decide which forecasting methods are the most suitable for any given task pricing is a much more evasive problem. The idea that profits can be maximized by carrying out a simple analysis of demand elasticity is deceptive. Indeed, pricing is a signal sent to the market; and like with any marketing ingredient, there is not one valid answer to the problem.

One year ago, most of the companies that helped merchants manage their pricing were consulting companies, but I wanted to build a pricing webapp to help businesses deal with their pricing which would go beyond the classic consulting services on pricing. I quickly ruled out the idea of offering a template list of “pricing recipes”. Some competitors were already offering such “pricing recipe” services, and they were desperately inflexible. Merchants needed to be able to “tweak” their pricing logic in many ways. Thus, I started to consider more elaborate user interfaces that would allow merchants to compose their own pricing strategies. After pushing some efforts at mockups, I was ending up with something oddly similar to Microsoft Access “visual” query designer.

This was not a good thing. My limited interactions with this query designer, a decade prior, had left me with the lasting impression of this being just about the worst user experience I have ever had with the “normal” behavior of a product released by Microsoft. While it was supposedly a visual query editor with plenty of very visual buttons, but unless you had some knowledge of SQL or experience in programming, you weren’t going very far with this tool. In the end, anyone using Access was falling back on the non-visual query editor, which quite unfortunately, was a second-class citizen.

Gradually, I came to consider the possibility of going for a programming language instead. With a programming language, we could provide the desirable expressiveness, but also a powerful data environment. Lokad would be hosting the data along with offering a cloud-based execution environment for the pricing logic. This environment would not be constrained by the client’s desktop setup which can be too old, too weak, too messy or downright corrupted.

At first, I considered reusing an existing programming language such as JavaScript or Python. However, this presented two very specific challenges. The first challenge was security. Running server-side client code seemed like a giant vector for entire classes of injection attacks. In theory, it should be possible to sandbox the execution of any program, but my instincts were telling me that the surface attack area was so great we would never be confident enough about not having leaks in our sandbox. So, we would have to leverage disposable VMs for every execution, and it seemed that an endless stream of technical problems was heading our way if we were to implement this.

The second, and in fact bigger, problem is that JavaScript or Python being full-fledged programming languages are also complex languages, which include truckloads of features downright irrelevant for the pricing use cases that I was considering: loops, objects, exceptions, nil references. No matter how much we would try to steer the usage of our future product away from these elements, I felt that they would invariably resurface again and again because some our future users would be familiar with just these languages, and as a result, they would do things the way they were used to doing them before. It is tough to debug a generic programming source code, so the tooling would necessarily end up being complex as well.

This left me with the prospect of inventing a new programming language, and yet this idea was accompanied by all the red flags possible in my mind. Usually, for a software company, inventing its own programming language is a terrible idea. Actually, I had witnessed quite closely three companies who had rolled out their own respective programming languages, and for each one of these companies, the experience was very poor to say the least . Two of them managed to achieve a certain level of success nonetheless, but the ad hoc nature of the language had been a huge hindrance to the process. Moreover, about every single experience I ever had with niche programming languages (hello X++) confirmed that an ad hoc language was a terrible idea.

However, as far pricing and commerce were concerned, a generic programming language was not required, and we were hopeful that through extreme specialization, we could produce a highly specialized language that would, all being well, compare favorably with the mainstream languages, at least for the narrow scope of commerce.

And thus, the Envision programming language was born at Lokad.

Unlike a generic programming language, Envision is designed around a relatively rigid and relatively simple data model that we knew to work well for commerce. My intent was to be able to reproduce all the domain-specific calculations that nearly all merchants were doing in Microsoft Excel, but putting some distance between the logic and the data - but not too much distance either. Indeed, Envision, as the name suggests, is also heavily geared toward data visualization; again, not generic data visualization, but things that matter for commerce.

Envision has no loops, no branches, no nulls, no exceptions, no objects … and it does just fine without them. It is not Turing-complete either, so we do not end up with indefinite execution delays.

Less than one year after starting to write the first line of code for the Envision compiler, we have now secured over a million Euros through multi-year contracts that are to be (almost) completely implemented in Envision. To be transparent, it is not the language that clients are buying, but the service to be built with it. Nevertheless, over the last couple of months, we have been able to deliver all kinds of quantitative optimizations with Envision - not just pricing actually – and within timeframes that we would never had achieved in the past.

There are a two takeaways lessons to be learned from this initiative. First, ultra-specialized languages are still a valid option for vertical niches. While it is a very rough estimate, I would say that with Envision, when dealing with a suitable challenge, we end-up with about 50 times fewer lines of code than when the same logic is implemented in C#, the primary programming language used at Lokad. Yes, using a functional language like F# would already make the code more compact than C#, but it would still be far from being that compact. Also, with Envision, we get more concise code not because of we leverage highly abstract operators, but merely because the language itself is geared towards the exact problem to be addressed.

Second, when introducing a programming language, it should not be half-baked. Not only the language itself needs the good ingredients known to computer science – a context-free grammar written in Backus-Naur form for example; but a good integrated programming environment with code auto-completion and meaningful error messages is also needed. The language is only the first ingredient; it is the tooling around the language that makes the difference in terms of productivity. From the very beginning, we invested in the environment as much as did we invest in the programming language.

Also, having a webapp as the primary execution environment for your language opens up a lot of new possibilities. For example, unless you spend years polishing your syntax before releasing anything, you are bound to make design mistakes. We certainly did. Then, as all the Envision scripts were also hosted by Lokad, it was possible for us to rectify those mistakes, first by fixing the language, and second, by upgrading all the impacted scripts from the entire user base. Sure, it takes time, but better to spend a few days on this early on, as opposed to end up with broken language forever.

I have not delved much into the details of the Envision language itself in this post, but in case you would be interested, I have just published a book about it. The preview gives you access to the entire book too.

Ps: while I credit myself for initiating the Envision project at Lokad, it is actually a colleague of mine, Victor Nicollet, presently the CTO of Lokad, who came up with nearly all the good ideas for the design of this language and who carried about 90% of the implementation effort.

Monday
Mar192012

## Bizarre pricing, does it matter? (B2B)

My company has just released quantile forecasts upgrade. It's no less than a small revolution for us, however, unless you've got some inventory to manage, it's probably not too relevant to your business.

Another salient aspect is our new pricing for quantiles (the old pricing for classic forecasts remains untouched). Lokad is selling a monthly subscription, and if $q_i$ represents one of the actual quantile values retrieved by the client during the month, then the monthly cost $C$ is given by:

$$C = 0.15 \times \left(\sum_{i=0}^n q_i^{2/3} \right)^{2/3}$$

We hesitated to round 0.15 as $\frac{\pi}{2}$ because formula look better with Greek letters. Obviously, it's not simple, and most people would go as far as saying it's downright obscure, but it is really a good pricing, or just plain insanity?

To understand a bit where Lokad is coming from, let's start with the fact that we are a B2B software company. About 95% of competitors don't have any kind of public pricing: you can only ask for a quote, and then a talented sales guy will contact you to figure out your maximum budget, only to get back to you with a quote at 120% of the figure you gave him.

However, I strongly favor public pricing, not because it's more transparent, honest, fair, whatever, but because it's a massive time saver. At Lokad, we don't enter into time-consuming pricing negotiations except for the largest clients, where it does make sense to spend time negotiating.

The cardinal rule of software pricing is that it should capture the willingness to pay of the client, which, in B2B, is typically related to the economic gains generated by the usage of the product. In the case of demand forecasting, benefits can be accurately computed. However, turning this forecasting benefits formula into a pricing formula is insaly complex in the general case.

Hence, we decided to settle for heuristics that somehow mimic this theoretical willingness to pay, ran many simulations over our existing customer base, and finally figured out the formula. I do not claim that this pricing formula is optimal in any way: it is not. However, it does bring a very reasonable pricing for clients ranging from 1-man companies to 100,000+ employees companies.

Pros:

• (As far we can judge) It's aligned with the value Lokad creates for clients.
• It's still simple enough to be memorized in 20s.
• It does not put incentive to game the pricing by excluding slow movers (i.e. products with low sales) from the forecasting process.
• There is no threshold effect, where the pricing jumps to a much larger number just because the company has 1 more product than what the license would support.

Cons:

• It certainly falls into the category of bizarre pricing.
• The only way to know for sure the real monthly cost is to give a try (1).
• Some prospects try the pricing formula on their own, and get it wrong (2).

(1) This statement applies to most metered SaaS, even if the pricing is linear. For example, at Lokad we had very little clue about our exact bandwidth consumption until we migrated toward the cloud (with dedicated servers, bandwidth was part of the package).

(2) I believe this partly explains why 95% of our competitors don't put any public price on display. That, and the fact that a very expensive pricing is likely to scare away prospects, before getting the chance of cornering them into the sales process.

I would be interested to see if other B2B niches have designed their own bizarre pricing formulas. Don't hesitate to submit them in comments.

Wednesday
Feb222012

## Cloud questions from Syracuse University, NY

A few days ago, I received a couple of questions from a student of Syracuse University, NY who is writing a paper about cloud computing and virtualization. Questions are relatively broad, so I am taking the opportunity to directly post here the answers.

What was the actual technical and business impact of adopting cloud technology?

The technical impact was a complete rewrite of our codebase. It has been the large upgrade ever undertaken by Lokad, and it did span over 18 months, more or less mobilizing the entire dev workforce during the transition.

As far business is concerned, it did imply that most of the business of Lokad during 2010 (the peak of our cloud migration) has been stalled for a year or so. For a young company, 1 year of delay is a very long time.

On the upside, before the migration to the cloud, Lokad was stuck with SMBs. Serving any mid-large retail network was beyond our technical reach. With the cloud, processing super-large retail networks had become feasible.

What, if any, negative experience did Lokad encounter in the course of migrating to the cloud?

Back in 2009, when we did start to ramp up our cloud migration efforts, the primary problem was that none of us at Lokad had any in-depth experience of what the cloud implies as software architecture is concerned. Cloud computing is not just any kind of distributed computing, it comes with a rather specific mindset.

Hence, the first obstacle was to figure out by ourselves patterns and practices for enterprise software on the cloud. It has been a tedious journey to end-up with Lokad.CQRS which is roughly the 2nd generation of native cloud apps. We rewrote everything for the cloud once, and then we did it again to get sometime simpler, leaner, more maintainable, etc.

Then, at present time, most our recurring cloud problems come from integrations with legacy pre-Web enterprise software. For example, operating through VPNs from the cloud tends to be a huge pain. In contrast, modern apps that offer REST API are a much more natural fit for cloud apps, but those are still rare in the enterprise.

From your current perspective, what, if anything, would you have done differently?

Tough question, especially for a data analytics company such as Lokad where it can take 1 year to figure out the 100 magic lines of code that will let you outperform the competion. Obviously, if we had to rewrite again Lokad from scratch, it would take us much less time. However it would be dismissing that the bulk of the effort has been the R&D that made our forecasting technology cloud native.

The two technical aspects where I feel we have been hesitating for too long were SQL and SOAP.

• It took us too long to decide to ditch SQL entirely in favor of some native cloud storage (basically the Blob Storage offered by Windows Azure).
• SOAP was a somewhat similar case. It took us a long time to give up on SOAP in favor of REST.

In both cases, the problem was that we had (or maybe it was just me) not been fully accepting the extent of the implications of a migration toward the cloud. We remained stuck for months with older paradigms that caused a lot of uneeded frictions. Giving up on those from Day 1 would have save a lot of efforts.

Wednesday
Nov232011

Among the (small) community interested by the software practices of Lokad to develop entreprise software over Windows Azure, Lokad.Cloud vs Lokad.CQRS comes as a recurring question.

It's a good question, and to be entirely honest, the case is not 100% solved even at Lokad

• from different backgrounds:
• Lokad.Cloud orginates from the hard-core data analytics back-end.
• Lokad.CQRS originates from our behavioral apps.
• with different intents:
• Lokad.Cloud wants to simplify hard-core distributed algorithmics.
• Lokad.CQRS wants to provide flexibililty, auditability, extensibility (*).
• and different philosophies:
• Lokad.Cloud is a sticky framework, it defines pretty much how your app is architected.
• Lokad.CQRS is more a NoFramework, precisely designed to minimally impact the app.

(*) without compromising scalability, however scalability is not the primary purpose.

Then, historically, Lokad.Cloud has been developed first (which is a mixed blessing), and, as we have been moving forward, we have started to partition into standalone sub-projects:

• Lokad.Cloud.Storage, the O/C mapper (object to cloud), dedicated to the interactions with the Azure Storage.
• Lokad.Cloud.AppHost, an AppDomain isolation layer to enable dynamic assembly loading within Azure Worker roles (aka reboot a VM with new assemblies in 5s instead of 5min). (**)
• Lokad.Cloud.Provisioning, a toolkit for the Windows Azure Management API.

(**) Lokad.Cloud does not leverage Lokad.Cloud.AppHost yet, it still relyies on a very similar component (which was developed first, and, as such, is not as properly decoupled than AppHost)

The case of Lokad.Cloud.Storage is a bit more complicated because Lokad.CQRS because Lokad.CQRS already has its own Azure Storage layer which focuses on CQRS-style storage abstractions. In particular, Lokad.CQRS emphasizes interoperable storage abstractions where the local file storage can be used in place of the cloud storage.

### The Future

As far I can speak for Lokad.CQRS (see the projet boss), the project will keep evolving focusing on enterprise software practices, aka not so much what the framework delivers, but rather how it's intended to structure the app. Then, Lokad.CQRS might be completed by:

• tools at some point such as a maintenance console.
• refined storage abstractions (probably event-centric ones).

In constrast, Lokad.Cloud will continue its partitioning process to become decoupled and more flexible. In particular,

• the cloud runtime
• the service execution strategy

are still very heavily coupled to other concepts within the execution framework, and likely candidates for sub-projects of their own.

I would not advise to combine Lokad.Cloud (execution framework) with Lokad.CQRS within the same app. At Lokad, we don't have any project that adopts this pattern, and the resulting architcture seems fuzzy.

Then, it's possible to adopt a SOA architecture where some heavy-duty functional logic gets isolated, behind an API, into the Lokad.Cloud execution framework, while the bulk of the app adopt CQRS patterns through Lokad.CQRS. This pattern has been adopted to some extent at Lokad.

Monday
Jan112010

## Scaling-down for Tactical Apps with Azure

Cloud computing is frequently quoted for unleashing the scalability potential of your apps, and the press goes wild quoting the story of XYZ a random Web 2.0 company that as gone from a few web servers to 1 zillion web servers in 3 days due to massive traffic surge.

Yet, the horrid truth is: most web apps won’t ever need to scale, and an even smaller fraction will even need to scale out (as opposed of scaling up).

A pair of servers already scales up to millions of monthly visitors for an app as complex as StackOverflow. Granted, people behind SO did a stunning job at improving the performance of their app, but still, it illustrates that moderatly scaling up already brings you very far.

At Lokad, although we direly need our core forecasting technology to be scalable, nearly all  other parts do not. I wish we had so many invoices to proceed that we would need to scale out our accounting database, but I don’t see that happen any time soon.

Actually, over the last few months, we have discovered that cloud computing have the potential to unleash yet another aspect in the software industry: the power of scaled-down apps.

There is an old rule of thumb in software development that says that increasing the complexity of a project by 25% increases the development efforts by 200%. Obviously, it does not look too good for the software industry, but the bright side is: if you cut the complexity by 20% then you halve the development effort as well.

Based on this insight, I have refined the strategy of Lokad with tactical apps. Basically, a tactical app is a stripped-down web app:

• not core business, if the app crashes, it’s not a showstopper.
• features are fanatically stripped down.
• from idea to live app in less than 2 weeks, single developer on command.
• no need to scale, or rather very unlikely.

Over the last couple of weeks, I have released 3 tactical apps based on Windows Azure:

Basically, each app took me less than 10 full working days to develop, and each app is addressing some long standing issues in its own narrow yet useful way:

• Website localization had been a pain for us from the very beginning. Formalized process where tedious, and by the time the results were obtained, translations were already outdated. Lokad.Translate automates most of the mundane aspect of website localization.
• Helping partners figuring out their own implementation bugs while they were developing against our Forecasting API was a slow painful process. We had to spend hours guessing what could be the problem in partner's code (as we typically don’t have access to the code).
• Helping prospects to figure out how to integrate Lokad in their IT, we end-up facing about 20 new environments (ERP/CRM/MRP/eCommerce/…) every week, which is a daunting task for a small company such as Lokad. Hence, we really need to plug partners in, and Lokad.Leads is helping us to that in a more straightforward manner.

Obviously, if we were reach 10k visits per day for any one of those apps that would be already a LOT of traffic.

#### The power of Windows Azure for tactical apps

Tactical apps are not so much a type of apps but rather a fast-paced process to deliver short-term results. The key ingredient is simplicity. In this respect, I have found that the combination of Windows Azure + ASP.NET MVC + SQL Azure + NHibernate + OpenID is a terrific combo for tactical apps.

Basically, ASP.NET MVC offers an app template that is ready to go (following Ruby on Rails motto of convention over contention). Actually, for Lokad.Translate and Lokad.Debug, I did not even bother in re-skinning the app.

Then, Windows Azure + SQL Azure offer an ultra-standardized environment. No need to think about setting up the environment, environment is already setup, and it leaves you very little freedom to change anything which is GREAT as far productivity is concerned.

Also, ultra-rapid development is obviously error-prone (which is OK because tactical apps are really simple). Nevertheless, Azure provides a very strong isolation from one app to the next (VM level isolation). It does not matter much if one app fails and dies suffering some terminal design error, damage will be limited to app itself anyway. Obviously, it would not have been the case in a shared environment.

Finally, through OpenID (and its nice .NET implementation), you can externalize the bulk of your user management (think of registration, confirmation emails, and so on).

At this point, the only major limitation for tactical apps is the Windows Azure pricing which is rather unfriendly to this sort of apps, but I expect the situation to improve over 2010.

·         not part of your core business, if the app crashes, it’s annoying, but not a showstopper.

·         features are fanatically stripped down.

·         from idea to live app in less than 2 weeks, single developer on command.

·         no need to scale, or rather, the probability of needing scalability is really low.

·         addresses an immediate need, ROI is expected in less than a few months.

Page 1 2 3 4 ... 4