Powered by Multi-access Edge Computing (MEC)
Until a few years ago, for many decades, telecom operators had been claiming that all they provided was a "dumb pipe". It was not their concern what those pipes carried; and they were not responsible for content that was served or consumed at both ends of the pipe. Their main goal was to ensure that the pipes had enough bandwidth to serve average and peak traffic requirements. All was well and good until over-the-top (OTT) content starting dominating the market. Such content bypassed legacy circuit-switched services and value-added services provided by the operators.
Indeed telecom operators started to lose both ends of the bargain. They now wanted control over the content and charge a premium but all they could collect from their customers was for bare bits and bytes. In a price-sensitive market, "unlimited plans" became the order of the day. When OTT content became predominant, operator revenues started to drop. Content also became rich in multimedia, particularly video that congested backhaul links. Operators couldn't afford to upgrade these backhauls. Yes, operators were providing dumb pipes but apparently even these had a hard time keeping up with demand.
An opinion on the diversity of cloud services
I've just returned from AWS Summit held at Taj Vivanta, Bangalore. It was a busy day of multiple back-to-back sessions interspersed with networking over tea, coffee and lunch. The venue was packed. The sessions were heavy, at least for someone like me who has never used AWS in any big way. I was familiar with some of the terms before coming to this event but I was surprised how much more there is to the AWS platform. They say that as a developer you can focus on developing your application while the cloud takes care of everything else: deployment, configuration, scaling, security, access control, monitoring, etc. While this is certainly true in the long term, as developers we need to put in upfront investment in terms of time and effort to understand the plethora of services that a particular cloud platform provides.
They say there are 90+ services in AWS. It's bad enough that developers need to aware of all these different services at their disposal. It's worse when you consider that making the choice of the right set of services for your application isn't trivial. This is particularly hard for folks used to only on-premise software built in monolithic fashion. We have to be really clear what we mean by the word "monolithic", which is usually not properly explained in such summits.
Payments made easy
It was in December 2016 that the BHIM app was launched by our Prime Minister. BHIM couldn't have asked for better timing. It came at the heels of demonetization when all of India was focusing on cashless payments. Cash was in short supply and alternative means of payments were in demand. About two months later, YourStory carried a story about 27-year old Nikhil Kumar who had apparently built the BHIM app in just three weeks. A few days ago Nikhil Kumar spoke at a small gathering of enthusiasts at Thought Factory, Bangalore. I attended mostly to know about UPI and BHIM but also partly out of curiosity to see the man behind the app.
I am yet to install the BHIM app on my smartphone. While I'm not a Luddite who stands against the advance and adoption of technology, I'm certainly not an early adopter. Since I know the engineering side of things, experience tells me that early releases are prone to contain bugs. Particularly in today's world of MVP releases and lean/agile processes, no one waits for a well-tested product. First releases will certainly contain problems when test-driven methodologies are not followed; or test automation has been sidelined due to more pressing delivery deadlines. So I haven't been using BHIM but I certainly wanted to know what it was.
The new kid on the block
The emerging IoT industry is an aggregation of products and services, complementing each other to enable efficiency and cost optimization in multiple industries. It does not have a vertically oriented value chain. IoT end nodes will be scattered in billions in various industries.
As mentioned in my earlier post ARM vs Intel: The new war frontiers, COTS processors will not be ideal for building these end nodes, as the latter are application specific. Companies would be inclined to adopt custom processors as they offer flexibility to assemble only required parts. These parts can include analogue sensor, DSP, proprietary IP, etc. Further, custom processors substantially reduce BoM cost and die size, which will minimize power dissipation. It also helps companies to differentiate their product from those of their competitors. In view of failing Moore’s Law, customization is the answer as it can reduce the BoM cost significantly.
A newcomer who's catching up with the competition
When it comes to cloud platforms, Google Cloud Platform (GCP) is probably not the first thing that comes to mind even though Google App Engine is quite popular. Google is taking cloud business seriously, where it has invested heavily in recent times. It has an aggressive roadmap in which new data centers are going to be set up worldwide, all interconnected via best-in-class fiber connectivity. Then there are the tools and APIs that developers can use to build their applications. There are deployment solutions that operations can use to manage their applications and their scalability needs.
I don't have much working experience with any cloud platform. I've dabbled with Microsoft Azure and IBM Bluemix but not done any serious work with either of them. I was therefore keen to learn about what Google has to offer. Today's event at their Google Bangalore office was just what I needed. Jointly organized by Sequoia Capital and Google, the event was the perfect overview of the entire gamut of tools and services that GCP has to offer. But the event was more than just an overview, thanks to many insightful questions from the audience. It was clearly an experienced technical audience and many of their questions brought clarity to the topics that otherwise might have remained at a superficial level.
Basic context, definitions and explanation
Today I attended Joomla Day Bangalore event hosted by Microsoft at their office in Domlur. I found a number of people new to Joomla and therefore decided to write this post outlining the basics of Joomla. As is usual in this blog, we keep it brief and avoid the use of difficult jargon.
In any website, there are broadly two groups of users: users who visit and interact with the website and administrators who maintain the website. In a static website where the content doesn't change and interaction is limited, the job of an administrator is minimal. The website is designed once, deployed and hardly ever modified. The more common case today is to develop dynamic websites, where content is dynamically generated. Here are some use cases:
- Different web page content may be generated for different users (eg. different access permissions are in place)
- Content served today may be different from content served yesterday (eg. news websites, stock prices)
- Content seen on a smartphone may be a slimmer version of what is shown on a desktop (eg. content adaptive to device)
In general, to make dynamic websites possible, you have to be a programmer. Server-side scripts based on PHP, Python, Node.js, Java, or any number of other languages execute on the webserver to generate the content dynamically. Does this mean that dynamic websites are inaccessible to non-programmers?
The future of cloud computing has already begun
There has been a lot of talk recently about serverless architecture and how it's the next big thing in cloud computing. Some even claim that it's really a natural evolution from monolithic web apps to microservices, and now to becoming serverless. But not everyone knows what is meant by serverless.
Is it possible to deploy an application without having a server? Does it mean that everything runs on the client browser or mobile app, with the role of the server reduced to mundane data fetching or updating databases? As developers, do we no longer need to care about scalability and response times from the server side of things? What we need is a clear definition of serverless architecture and its surrounding context.
Droids, cloud platforms, APIs and more
On Saturday we had our second edition of IoT Project Day, a quarterly half day session where our members get a chance to give demos on what they have done in the IoT space. Unlike other IoT meetups happening in Bangalore, the focus of this event is as always on the engineering aspects of IoT. In other words, we talk about technologies and tools, tips and tricks, optimization techniques, design and architecture, interfaces, mistakes and what we learnt from such mistakes ...
We had a good turnout of students and working professionals. It was good to see a couple of school students taking interest in electronics and IoT. There were seven demos. This article is a summary of the demos, which will be useful for those who were unable to attend the event. It was also a good networking session for us. I'm sure some of us will collaborate on a couple of projects that can be presented at the next IoT Project Day, which will happen in August. Thanks also to Microsoft for sponsoring the venue.