Word Battle at 30,000 Feet

One of the challenges of building an enterprise-class software platform in the cloud is making it reliable and high-performing over all types of wifi and cellular networks.  We spent a lot of time testing multiplayer TraceWord games on various crowded public wifi networks and on 3G and 4G networks across multiple service providers and signal strengths.

You would think that as long as you can connect to the Internet through any wireless network, everything should just work, but there are actually many ways in which both wifi and cellular networks can misbehave, from dropping data packets, to timing out after a certain period of time, to constantly dropping and re-establishing connections.  None of these situations are good for maintaining any sort of real-time activity, and the server system fielding and processing connections from mobile devices must be able to handle them.  Each time we tested the game over a new network configuration, we got a slightly different result and had to tune the server accordingly.

There was one network we hadn’t tried yet, though.  I just took a trip this past weekend, and they offered an in-flight wifi service for the passengers.  I signed up and got my pass code, and once we got above 10,000 feet, I was able to log in.  My son was excited because he figured he’d get to watch Netflix, even though I told him not to get his hopes up.  Sure enough, the connection was too weak and intermittent to maintain a video stream, even streams from YouTube.  I could check my email, but latency was long, and a couple of times it was unable to make the connection to my mail server at all and I had to keep retrying until it got through.  Granted, the plane was crowded, about 175 people, and I’m sure there must have been at least 20 to 30 people using the service, maybe more.

The service is likely designed to provide basic connectivity for email and static web browsing, and it was clear we could not expect to experience any rich media along the way.  Naturally, I got curious about how the Native Cloud Software Engine would perform under these conditions, so I opened Skype, and after several minutes of long waits while Skype worked to exchange a few short messages with Shannon (our founder/CTO), we agreed to get a game going.  I created a 2-player game, thinking that if Skype was even having this much trouble, there was a good chance we wouldn’t be able to get through a game.

Shannon joined the game and it started immediately. I found the first word, and the system acknowledged it quickly, and just as that happened, Shannon’s first word appeared selected on the board.  The battle had started, and the words were disappearing quickly.  The game’s responsiveness was impressive, with no apparent latency whatsoever!  It was all over in just under two minutes, no dropped players, no long pauses, no problems at all!  Plus I won, but it was neck-in-neck all the way!

So even at 30,000 feet, I discovered, our software engine really performed, and it’s a testament to the way our servers communicate with devices and process data communications.  Because we have deployed our own system layer in the cloud (Native Cloud OS) and we communicate with it using our own programming language (Native Cloud Language), we are able to provide a much leaner data communications channel than conventional systems.  This high level of communications reliability and performance is one of the main reasons we are able to call our technology Native to the cloud, and one of the many features of the Native Cloud Software Engine that make it such a disruptive player in the cloud programming platform space for game developers and enterprises alike.

Advertisement

The Last Programming Language You’ll Ever Need?

Programming anything that runs on the web or mobile devices these days is like opening a huge box of puzzle pieces that need to be put together without knowing what the whole puzzle looks like.  Being able to use cloud computing resources may absorb some of the infrastructure burden, but even in the cloud, servers need to be programmed.

As software engineers, we are, on the one hand, used to learning new languages and frameworks to get things to work the way we want them to, and on the other hand often faced with climbing mountains of complexity to reach our coding goals.  Because we are persistent, resourceful, and creative, we eventually figure out how to do what we want, but not without a lot of research, trial-and-error, and frustration along the way.  Then, several weeks or months later, we clink our glasses together to celebrate the release of our cool, new app and concur it was worth all the pain.

If you are a developer, you’re probably saying something like, “Yeh? So?” In other words, we’re just used to having to work this way and deal with these issues.  We manage complexity well, and we share our techniques on more efficiently managing the complexity.  We have a whole Internet of fellow developers to tap when we’re having trouble fitting a couple of particular puzzle pieces together, and eventually, we  get everything to fit, but it probably won’t be easy, and some of the pieces will likely still be loose fitting.

Now look at this complexity from another perspective.  From a technology standpoint, what we now call The Cloud is really no different than what we called a virtual hosting environment five years ago, and a colo facility ten years ago, and a data center fifteen years ago, and time-sharing thirty years ago.  What the cloud is really about is volume of data (amount of data stored, processed, served and streamed), efficiency, and cost.  What the cloud is not is easy to use as a programming platform, mainly because it is built with and held together by the same rat’s nest of disparate languages and connectors that it all started with nearly 20 years ago.  Sure, the tools have evolved along with the appearance of unprecedented access to online storage, processing, and communications tools, but programming on the cloud still requires weaving together markup languages with server-side scripting and database functionality, and there are several groups of these types of weavings, depending on whether you are a linux, Windows, Apple, IBM, or Oracle user.

The point is, while computing infrastructure now runs on fast, multi-processor hardware used to host virtual servers, the systems on which this infrastructure runs were never designed in the beginning to run such vastly distributed computing environments. That’s why it takes at least three programming languages to accomplish anything as a developer using these kinds of environments.  But at NCS, we refuse to accept this level of complexity anymore!

The Native Cloud Software Engine is designed from the ground up to maximize the advantages of multi-processor and distributed computing.  It basically runs a virtual operating system on cloud services in order to offer the cloud as a secure, high-performance, full-service platform for applications.  To take advantage of the full potential of this OS, we’ve created a language that thinks differently while providing both client and server-side application programming that encapsulates the shared data.

Through the Native Cloud Language, we’ve already bolted our engine into XCode/Objective-C via our iOS API, which is what we use behind our game TraceWord to provide the real-time processing and communications capabilities that make it an exciting, fast-paced multiplayer game.  There is no need to provision any servers or databases because the language has simple commands for configuring and using processing and various kinds of storage resources.

As we at NCS continue to expand the capabilities of our language and platform, we are actually finding ourselves needing to program less and less in anything besides Native Cloud Language, and we can’t help but think this actually may be the last computer language we’ll ever need to learn! It’s not a matter of being the one-language-to-rule-them-all, but rather the one language to bring them all together.  For now, we’ll have to settle for greatly reducing the number of puzzle pieces!  In any case, it’s the first language designed to support native applications in the cloud, and we look forward to sharing it, and our development tools, as we roll services out over the next few months.  Stay tuned!

NCS Introduces the Start of A New Era for Cloud Computing

We’re running down checklists at Native Cloud Systems as we approach the dual releases of our casual iPad game TraceWord, and the underlying Native Cloud Software Engine (NCSE) it will be running on. It seems like we’ve been in testing for eons, but it’s what we signed up for when we decided to build a product on top of our proprietary cloud server technology, and today it feels like we’re on the precipice of introducing a new era for cloud computing!

We learned early on that entering the market with a new cloud platform, no matter how much more secure, high-performing, and easy it is to use, is hugely challenging given all the hype and noise around cloud computing.  This is why we created TraceWord, a multiplayer version of a classic word search game, as an initial example of what our system is capable of.

TraceWord is written in Objecive-C, including the interface to the NCSE through our iOS API.  This allowed us to utilize cloud-based resources using Native Cloud Objects coded right into the game application. These objects do the work of matching players to games, shuttling data between players during games, and managing multiplayer game states, all with relatively few lines of code and zero setup of server resources of any kind.

We are excited to have finally reached this point where we can share both our software engine and a fun, exciting iPad game, and we look forward to elaborating on our products and their capabilities in the weeks to come! Check back for updates and news, we’ve got a lot to talk about!