Covalence

Let's Share

Introducing Molecule M.Functions​

Overview

Much has been said about micro-services over the last year and I wanted to find out for myself what the fuss was all about. At Molecule, we needed a way to augment our main application with supporting functions and services, and I figured it was time to give micro-services a shot. I looked at several open source technologies that promised to provide an easy-to-use micro-services platform. We ultimately landed on Knative given the strong community support around the technology and how the technology met our needs.

I used the following as guiding principles for evaluating the various micro-services technologies:

  1. Strong community support
  2. Integrates with our GitLab and Kubernetes Continuous Integration(CI)/Continuous Delivery(CD) tooling
  3. Supports our primary use cases
  4. Extends to our customers

Strong Community Support

As with any open source technology, strong community support is a must-have. Even if it's great tech, but does not have a good developer community supporting the technology, best to look for something else. In Knative's case, there is active community support on GitHub and a thriving Slack community. And of course, Google is behind the technology.​

Integrates With Our Existing CI/CD Tooling

It was important for me to not add yet another tool to our engineering workflow and to ensure we can leverage our existing CI/CD tooling. We were already heavy users of GitLab for our source code management and Docker image registry as well as AWS EKS (Kubernetes) to run the Molecule app. Our chosen micro-services platform needed to work within our current infrastructure.

To run our Knative instance, I ended up creating a separate AWS EKS cluster from our main production cluster to allow us to more easily upgrade our Knative cluster as needed and to avoid any unintended consequences to our production cluster. The following components are installed in the EKS Knative cluster:

  1. Knative Serving and Eventing
  2. Istio
  3. Kafka (as a messaging provider)

The Knative cluster consists of two primary namespaces, molecule-functions-dev for services under development and testing and molecule-functions that are serving production workloads. In GitLab, each function is a separate project with an accompanying .gitlab-ci.yml file to manage the build of the service and the auto-deployment to the appropriate namespace in the K8s cluster. When a change to a function is merged to the master code branch, the Knative service is built and auto-deployed to the molecule-functions-dev namespace. When a tag is applied to a function, the Knative service is auto-deployed to the molecule-functions namespace. Included in the build and deployment is the K8s service.yaml file which describes the service and any supporting deployments such as a cronjob.yaml, if one is required for scheduled services.

With this approach, our developers as well as our customer success team can live in their favorite IDE, and easily develop, maintain, and deploy scalable Knative services simply by committing and tagging code in GitLab.​

Supports Our Primary Use-Cases

At Molecule, our chosen micro-services platform needed to support the following use-cases:

  1. Can it run on a schedule?
  2. Can it be executed on-demand?
  3. Does it support messaging?
  4. Can it scale?

On a Schedule

We have multiple instances where we need to run a function on a schedule to allow our customer success team or our development team to execute routine functions that allow us to maintain the health of the Molecule app. Knative's CronJobSource provides a straight forward mechanism to schedule these routine functions. Examples of routine scheduled functions include data integrity checks, cleaning up obsolete log data, and nightly resetting our alerting system.

On-Demand

To help extend the core Molecule application, our services needed to be reachable from the Molecule app that would allow us to execute custom services that we develop on behalf of our customers or services that we want to run outside of our production cluster. For example, our asset valuation module can call external services either hosted by our customers or hosted by us that returns custom valuation data to Molecule. These services can now run in our Knative cluster allowing us to scale these services as needed.

Message Based

Guaranteed and reliable messaging is critical to any enterprise system, particularly commodity trading and risk management systems like Molecule. We reliably utilize messaging today within our core Molecule app to scale our back-end processes; however, we also have a need to utilize messaging outside of our core app to support business critical functions on behalf our customers. For example, our batch reporting functionality relies on messaging to distribute the creation and publication of batch reports (e.g. trade confirms) to our customers. In our Knative cluster, we utilize Kafka as a guaranteed message transport to ensure a message reaches its destination and performs the intended function.

Scalable

Scalability is another critical component of a good micro-services architecture that supports the scaling of services to meet demand as well as scaling to zero for non-critical services that can tolerate a cold start. Knative supports this requirements nicely by allowing us to set scaling parameters at a per service level supporting scaling to 0, setting a default number of always-on service replicas to respond to normal demand, and setting max scaling levels to control the workload in peek demand.​

Extends to Our Customers

A primary reason for adding a micro-services based approach to our ecosystem is to better support our customers and to provide them with the functionality that is required to do their business without having to resort to core application changes. As stated above, our Knative cluster allows us to quickly and easily develop, deploy, and scale business critical services to augment our core application and also enables us to better serve our customers. This platform also positions us to provide future services to our customers such as our customers running their own developed and managed services in our managed Knative cluster to further extend their use of Molecule.

Conclusion

With all the benefits and capabilities of a micro-services platform outlined above, we have embraced micro-services as an extension to our platform and we are now referring to this collected set of capabilities as Molecule's m.functions.

SoftwareFeatures

2019 In Review

Molecule is always evolving, and it’s really fun for us to look backwards every so often, just to see how far we’ve come. It’s easy for us to forget all the cool new features we’ve added over the course of 525,600 minutes. Hopefully, our work made your daily work just a little bit easier!

Here are some of the things we made this year:

New Trades Screen

After lots of customer feedback and tons of research & development, we launched a new Trades screen. On it, you can now pick the columns you want to see, sort and filter, create saved views for different types of trades, and much more.

It looks fantastic, too — and performs like crazy. Underlying it is a brand new front-end framework and an awesome grid that we plan to continue upgrading. If you don’t have access to it already, just ask your Admin.

New API

Our new v2 API began rolling out last year, and we completed the rollout late this year. Using it, users can do a million and one things, including:

  • Connect Molecule to Excel PowerQuery or Microsoft PowerBI for powerful, even mobile analytics.
  • Stitch another system to Molecule to send or retrieve trades, market data, valuations, or even VaR details.
  • Set up your master data in Molecule, and manage it.
  • Get pretty much any data out of Molecule you want.

Moreover, our new screens (like the Trades screen) use it, too — so we’ll be adding new features to it and improving it all the time. If you haven’t used it yet, documentation for our new API is at https://developer.molecule.io. (The documentation password can be obtained from our CS team.)

VaR out of Beta/Backtest

Our long-maturing VaR finally came out of Beta this year. It’s stable, it’s been running on multiple different portfolios for months, and it’s FAST. We also rolled out a visual backtest — to prove that it’s generally right.

Much Better Hourly (and sub-hourly) Power Model

Molecule began with a focus on power and then expanded to other commodities. This year, we upgraded our power capabilities to better model hourly (and even 15-minute) power — without shoving hours into product names, but by attaching intervals to contract dates system-wide and across all major integrations.

We rolled out the first of the power upgrades at the end of December, and plan to have all accounts migrated to our new model by the end of Q1 2020.

Self-Administration

A common customer request is to bypass our Customer Success team and allow users to self-manage things like master data and user access. We rolled out the first of the screens to manage this — our new Counterparties screen — this year. We plan to add much more in terms of self-administration capability in 2020.

Consumable & Inventory Trades, Logistics Preview

Early in 2019, we began sharing our physical logistics preview. We’ve been taking on board lots of great feedback—to iterate on it so that we get it right. New enhancements now include “consumable” trades, for things like transportation, RECs, RINs, and “inventory” assets, which allow for multiple buckets of inventory valued in a custom way.

Wrap Up

We made a whole lot more — over 550 improvements, big and small, to Molecule this year. All while improving reliability to 99.98% (less than 1 hour of unscheduled downtime), and improving general performance as well.

We’re equally excited about the things we have planned for next year: from single sign-on, to user-feedback-driven upgrades for many of our screens, and even more features related to self-administration and quality assurance.

Thank you for using Molecule (or just following our progress). We hope we’ll blow your socks off next year.

Love,
The Molecule Team

Features

What will I Save by using Molecule?

We frequently get questions asking how our pricing model works, especially as compared to other vendors in the ETRM/CTRM industry. In answering the question "What will I Save?", we first need to understand the pricing model for legacy (or on-premise) software.

Legacy Systems

Typically, with on-premise (or even single-tenant cloud) software like an ETRM, pricing has three components:

  • Perpetual License Fee
  • Annual Maintenance
  • Services (i.e., installation)

For a mid-size ETRM/CTRM customer, let's say the license fee is $1m on a 4-year contract. This is the most negotiable part of the contract because 1) it's not where the real money is paid and 2) the underlying variable cost (what it costs to send you the software) is essentially $0.

The annual maintenance fee, however, is where the margin gets real. Annual maintenance is often 20% of the standard pre-negotiation license fee. So, $200k/year in this example. This is less negotiable because this money pays for the development team. We've also heard of this as "the money that pays for new features and bug fixes," which makes our sales team go crazy.

Services – now here's where the major cost lies. On a greenfield ETRM/CTRM implementation, services can start at several hundred thousand dollars. However, implementations typically go into the millions, or even tens of millions (not because they're budgeted that way, but because they quietly end up ballooning in scope and time). The cost is unbounded – and from what we've seen, services is typically 75% of the total cost to the customer of an ETRM/CTRM installation. (CTRMCenter has an article on this, here). This is the case for numerous good and bad reasons. But, from our perspective, the most important reason is that because of a time-and-expense billing schedule, vendors are not incentivized to keep billing for services low.

Molecule

Molecule is different. In general, users pay a single package price, plus applicable sales tax. That's it. The price includes implementation, "paying for new features," the license fee, etc.

We have a minor fee schedule for a handful of things like new users, custom reports, and re-configuration of the application – but most of our customers never pay any additional fees.

Package prices are calculated, on purpose, to be roughly equivalent to the 4-year amortized license fee + maintenance fees of another ETRM/CTRM. This takes into account that license fees are often heavily discounted for smaller customers – but the point is, we're not aiming for the lowest license fees in the industry.

What users just don't pay for with Molecule is implementation. We take on the risk of new implementations knowing that the payoff for our customers (and for us) is enormous. We are aggressive about bounding the total cost and time of the implementation – because we are incentivized to do so. We do things like:

  • Assigning an expert project manager on Day 1
  • Avoiding implementation-related travel, if at all possible
  • Figuring out what "success" means for the customer, and keeping laser-focused on that goal
  • Building tooling for our Customer Success (support & implementation) team, so that they can get their job done more quickly

This is how we create the most value. We believe that implementation costs, in Six Sigma terms, are waste (muda, mura, and/or muri). Our customers don't benefit from paying tons of money for implementation, and neither does our enterprise value.

Summary

Basically, our customers pay industry-standard software fees – but end up saving 75% of the total cost of an ETRM/CTRM because we don't charge for implementation.

SalesFeatures

Tackling ISOs and FTRs

From a development roadmap point of view, Molecule's decision to connect with ISOs and value FTRs was a bit of an outlier. We tend to have a solid understanding of what our customers want, and we use this insight to build features with wild-eyed speed and focused precision. ISO connectivity and valuing FTRs came about in a different fashion, however.

As Sameer, our CEO, and I sat in a room (OR at the table with eight execs representing one of the largest European utilities), the conversation unfolded in an unpredictable way. Deal capture and risk is our bread and butter, so we demonstrated how Molecule automates as much as possible. We believed we had nailed everything around what they could possibly need from a risk management platform, and we felt we had won the room. Our free implementation and implementation time frame (typically 90 days or less) was the icing on the cake. It was a great meeting.

Then someone asked about ISOs and FTRs. At the time, we did not have this feature. The challenge was laid out. Could we add that in the 90 day implementation for a deal to happen? As Sameer considered the industry's need for features around congestion, I held my breath. As you can surely guess, the answer came swiftly: yes.

Our in-house Development Team started banging out code before the ink could dry on the deal. Starting with SPP and PJM, we dived deep into valuing FTRs.

During the implementation process, Molecule aimed to provide support for FTRs, Virtuals, & day ahead power. The challenge landed on the lap of our SVP of Engineering, Paul Kaisharis. Speaking with Paul, he was quick to discuss the challenges around delivering our new solution: "understanding the domain terms and normalizing those terms as well as the implementation across the various ISOs." He was equally quick to discuss what he was most proud of: "creating a standard implementation that allows us to add support for a new ISO in just a few days."

Kyle McRoberts, a key member of our Customer Success team, chimed in as well, "I’d say the most challenging and rewarding part of the FTR implementation was simply the volume. Right now we have close to 7,000 paths available in Molecule, each with a peak and off peak product. The other challenge is that we simply don’t know when new paths are needed until the auction results are posted. We’ve got a process in place now to create new paths when needed (for example, over 500 today) mostly without the customer knowing they needed to be created."

Joe, our VP of Customer Success, was another integral piece in the FTR puzzle. He said, "the challenge: the large number of moving parts involved in this implementation and putting them all together working with multiple vendors as well as divisions within the client organization. What we are most proud of: implementing FTRs with a large number of paths with multiple ISOs for a big multinational company in a short period of time."

We are by no means a custom shop. Molecule builds modern deal capture and risk for everyone. Every customer benefits from our two-week release cycle with free updates and support. Paying for 'future code' is absurd to us. We love our customers. And we listen to them. We take their suggestions and look at the industry with the future of commodity trading in mind. Then we build kickass tech.

What's next? Physical scheduling. Stay tuned.

Features

The Saga of VaR

One of Molecule’s most important product development milestones to date has been releasing our dead-simple, near-real-time Monte Carlo VaR. It’s taken us years to do, unlike literally every other feature we have built.

Why? Part of the reason is that it’s a complex calculation that’s difficult to present simply, consistently, and clearly. Also, it’s both important and difficult to get right -- and to prove that it’s right.

So we enlisted the help of a superstar: Dr. Ehud Ronn, a professor at the McCombs School of Business at the University of Texas. With his help, we built a validation framework and tested our goods.

On Thursday, July 27 at 1pm CT, we invite you to join Ehud and Sameer Soleja, Founder and CEO of Molecule Software to learn more about:

  • Why it was so difficult for us to build - and to get right
  • What a "right" VaR even means - that’s a head-scratcher, we know
  • How we validated our approach and how you can validate yours
  • When Ehud will be able to actually predict the future (Molecule Release #10,317)

Our new VaR is awesome. It’ll make you want to throw your spreadsheets out of the proverbial window. Imagine--you know that your VaR is right, and you don’t have to do anything to make it so! Join us to learn more about it.

There are limited places available for this webinar, so we encourage you to save your spot as soon as you can. Click here to register.

FeaturesVaR