m
Our Mission Statement
This is Photoshop's version of Loremer Ipsn gravida nibh vel velit auctoregorie sam alquet.Aenean sollicitudin, lorem quis bibendum auci elit consequat ipsutis sem nibh id elit.
Follow Us
Top
Impressions from the Austin, TX Telco 5G/BCE Show - VoltDB
9357
post-template-default,single,single-post,postid-9357,single-format-standard,mkd-core-1.0,highrise-ver-1.0,,mkd-smooth-page-transitions,mkd-ajax,mkd-grid-1300,mkd-blog-installed,mkd-header-standard,mkd-sticky-header-on-scroll-up,mkd-default-mobile-header,mkd-sticky-up-mobile-header,mkd-dropdown-slide-from-bottom,mkd-dark-header,mkd-header-style-on-scroll,mkd-full-width-wide-menu,mkd-header-standard-in-grid-shadow-disable,mkd-search-dropdown,mkd-side-menu-slide-from-right,wpb-js-composer js-comp-ver-5.2.1,vc_responsive
VoltDB / In-Memory Database  / Impressions from the Austin, TX Telco 5G/BCE Show

Blog

Impressions from the Austin, TX Telco 5G/BCE Show

VoltDB has been providing value to telco communications solution providers since our beginnings back in 2009. Back then, we were designed into OSS/BSS software offered by companies like Openet and HP (now HPE) because our database could make the very fast authorization/authentication decisions that were needed while offering the high reliability required by carriers. Our in-memory transactional database also offered a very low TCO, especially when compared to larger traditional databases, allowing these software vendors to sell solutions into new emerging markets at a very attractive price and to maintain their margins.

We noticed that our message about our “NewSQL” database really resonated with telcos, as well as with financial services firms, both of which were very familiar with the benefits of true SQL databases. Some had felt the need to stray from SQL databases and try some open source NoSQL data platforms in order to get scalability and availability for web-scale operations as well as to try to lower their data management licensing costs. After all, open source means free, right?

But then came regrets and second thoughts. More thoughts on that below.

I attended Light Reading’s Big Communications Event in Austin, Texas (held together with KNect365’s 5G North America show) a few weeks ago. A key topic for that show was open source, the good and the bad.

Open Source: Can Never Have Enough?

It started with the opening session. Steve Saunders, Founder of Light Reading, started off with a very provocative keynote (you can watch it here). He posited that the telco industry is way behind on their planned migration to NFV and SDN because of three main culprits – the first and main one being the open source community. As Steve said, the good news about the open source community is they have an unlimited number of good ideas, but the bad news is they have an unlimited number of good ideas. His point was that open source provides many options, sometimes too many options, which has kept telco firms from converging on standards, which are so critical for telco solutions stack interoperability.

I think Steve was being overtly provocative to provide a prompt for conversation for the rest of the conference, and he was successful in doing that. One thing that could not be argued is that it has taken the telco industry too much time to build out a new infrastructure blueprint that can offer new, needed services in an agile and reliable way, without the complexity and cost of custom/proprietary hardware and software stacks.

The Conundrum of Open Source: Lots of options can be good…and bad

I’ve heard this same conundrum expressed by some of our customers. There are many open source projects, so you can usually cobble together some combination to do just about any kind of data management function you want, which is great. But the combination you create is usually unique, so you become a pioneer with your particular solution “stack”.  And that leads to a complication — the projects don’t necessarily play nicely together, particularly when one or more fails. Each project may be pretty robust and well-tested across a wide spectrum of use cases, but chances are that your particular combination of projects may not be. You need to write the glue code between the components and figure out how to gracefully recover each component should it fail. That has to be in context of the combination — for example, do you need to fail and recover all the components (and in what order), or can your structure tolerate enough back pressure from the failed component to recover and catch up gracefully?

Maybe we do have too many choices in the open source world, and those choices have caused telcos a certain amount of analysis paralysis. Studies show that more choices aren’t necessarily better in helping you choose — here’s just a sample from a quick Google search:

I suppose the same argument could be applied to commercial software. Steve went on to throw some of the blame for telco foot-dragging on virtualization at software vendors and analysts as well — but a certain amount of economic evaluation is done before a software company brings a product to market and Darwinism has a fast impact in the commercial software space, so I think there are more limiters governing the number of similar commercial software products available at any point in time.

So open source — is it a case of the more the better, or less is more?