My short time with T-Mobile: the good, the bad and the ugly

After 15+ years with AT&T Mobile I decided to switch to T-Mobile. The reasons I switched to T-Mobile are in the Good section. The reasons are went back to AT& are in the Bad/Ugly sections. I was with T-Mobile for five days and used the phone in the Bay Area (east bay and San Francisco).

The Good

  • Excellent customer service. Any time I reached out to them on Twitter via DM, I’d get a reply within 10-15 minutes. They genuinely want to help you 👏
  • Price. T-Mobile monthly price per line is usually $10-$15 cheaper than AT&T or Verizon. For example, right now they have a promotion where you pay $40/line. For three lines it is $120 and the nice thing is that all taxes and fees are included. In California, you get close to $5/line in taxes and fees. They also include Standard Netflix subscription (with 2 or more lines), that’s another $10.99 🤑
  • I like their Un-Carrier principles 🙌
  • It’s also fun to watch their CEO John Legere tweet and make fun of the competition 🤪
  • Extra benefits such as texting and data abroad (although at very slow speed), free in-flight texting on Go-go enabled flights (and one hour free internet) ✈️
  • If coverage where you live is not good, T-Mobile will send you a free CellSpot or signal extender for free. CellSpot connects to your WiFi and creates a mini cell tower right in your house 📶

The Bad

  • Coverage is weak. In places where their coverage map shows strong coverage, you get weak coverage. My service was showing 1-2 bars most of the time 👎
  • T-Mobile support will offer you a free CellSpot or signal extender if coverage where you live is not good. I think they know their coverage is not good so they right away offer these units for free 📡
  • Call quality (voice) is not as good (at least compared to AT&T).☎︎
  • Many other people are also reporting that they have bad service/coverage 📴
  • Anytime you tweet about bad coverage (like here), T-Mobile support will respond (that’s good) and tell you they will help. After a few tweets like that you realize there is nothing they can do (they can’t magically add more towers) 🙅‍♂️
  • T-Mobile CEO John Legere making of the competition is fun at the first. When you realize the service is far behind the competition, these tweets are not as fun anymore 😶

The Ugly

  • Coverage inside buildings is very bad and in some cases non-existent.  I was in the heart of San Francisco with virtually no coverage inside an office building even thought their coverage map said it was in strong coverage area 😡

The Disappointment

I was eager to try T-Mobile due to everything I listed in the Good section. I was genuinely surprised and disappointment at how poor quality their service/coverage is in 2019. I always knew that T-Mobile was behind AT&T and Verizon in coverage but I didn’t realize how far behind, even today. I complete understand that each carrier has some areas where coverage is not good but I was expecting much stronger service/coverage in the San Francisco Bay Area and coverage inside buildings is even worse 😔

I think T-Mobile knows its network is not as good and so has to be different than AT&T/Verizon on something else – and that something is lower prices (and that does attract new customers).

I like T-Mobile and what they stand for. T-Mobile is in the process of merging with Spring. I hope after the merger is finalized, they will significantly improve their coverage and I will give them another try 🙏

 

 

Should you migrate an existing enterprise Java application to serverless architecture?

Last week Marek Sadowski and I presented Introduction to Serverless with IBM Cloud Functions: a new way to build modern apps at Silicon Valley JUG. 

One of the questions from the audience was how do you take an existing large enterprise Java application and migrate it to serverless architecture? 

The short answer is you probably shouldn’t do it.  

But let’s look at the long answer. 

Unless there is a very good reason, there is little value in taking a large existing enterprise Java application and migrating it to serverless architecture. I think serverless should be considered for new applications in most cases.  Now, if you need to add a small new feature to an existing application, you could look at serverless.

For example, if you are running a large loyalty application (airlines, hotels, etc) and you have a new requirement where you need to process new members once a day. Once a file is received/uploaded, a function can be executed to process the new members.  

Or, you can migrate small bits from an existing application like a cron job or a queue process. But again, there is probably little value in doing a complete re-write. 

Serverless cold start is not a problem – and here is why (for most applications)

When you start with serverless you will very soon learn/hear about functions cold start (I believe serverless = cloud functions + APIs). A cold start happens when a cloud function is invoked for the first time or after a long time of no invocations. Basically, it takes the server (yes – there are servers!) a little bit longer to get the function ready the first time, so it’s ready to accept and process the request. If a function is invoked a second time, it will execute faster. There is a time period during which a function stays warm. If a function is invoked again during that time period – it will be executed fast.

If a function is not invoked within some period, it becomes cold again and the next time it’s invoked, it will be a little bit slower again (cold start).

This makes sense. When you launch an app on your phone or computer for the first time – it takes a little bit longer the first time. When you launch it again very soon, it usually starts faster.

For many applications cold starts are not a problem. It’s very important we consider the type of application we are building. If we are building a business application or an internal backend application – then cold starts are not a problem. It’s not going to make a difference if an application starts a fraction of a second slower or responds to a request a fraction of a second slower. Type of an application is important when talking about cold starts. It’s only a problem for some applications and probably in those cases serverless is not the best fit.

Continue reading “Serverless cold start is not a problem – and here is why (for most applications)” →

Video: Serverless – a new way to build modern applications

Curious about serverless/function-as-a-service/cloud functions technologies, but haven’t had a chance to dig in? Wondering what all the excitement is about? Serverless doesn’t mean no servers. It’s a new way to build modern applications. Watch this video to learn more about this new approach to building modern applications. The video covers:

  • The current state of the serverless ecosystem & major players
  • Recognized ideal use cases for serverless solutions
  • Best practices for serverless architecture
  • Good sources of information to keep abreast of new developments
  • Live coding example

If you want to learn more about this topic, please read this blog post: Serverless – simply an approach to building modern applications?

Serverless – simply an approach to building modern applications?

If you search for “serverless” you find that serverless is a new popular way to build modern applications. Is serverless really new?

Serverless refers to the notion that you don’t need to worry about servers – you don’t need to provision, deploy, maintain servers. Obviously there are servers but you don’t need to think or worry about them, the cloud or the platform where you run the code will take care of that for you. Another major benefit is that a serverless function (cloud functions or function as a service) will automatically scale when demand increases.

Interestingly, the idea of executing code in the cloud has existed for a long time as part of Backend as a Service (BaaS) or Mobile Backend as a Service (mBaas). Companies such as Parse (Founded in 2011. Acquired by Facebook and now lives as an open source project), StackMob (acquired by PayPal), Kinvey (acquired by Progress), Appery.io (my previous company) and many others.

In addition to providing a server-side environment where a developer can write and execute code, these companies provided additional services such as a database, integration with 3rd party API and services, push notifications (for mobile), analytics, file storage, integration with login providers and other capabilities. They also provided various client SDK to work with their backend services.

I think serverless is simply an approach to building modern applications. It’s not a particular feature, but an approach. As for naming, I personally prefer the name cloud functions or functions-as-a-service.

Continue reading “Serverless – simply an approach to building modern applications?” →

What I Learned Attending a Serverless Conference

Four weeks ago (this week) I attended the Serverlessconf in San Francisco. The following are my notes, observations, opinions and pictures from the conference (in no particular order).

Serverless Awesome 😎

Serverless is awesome because:

  • Build apps faster
  • Development focused
  • Serverless architecture offers the most productivity and agility
  • Never think about servers
  • Never think about cost (🤔)
  • Never think about performance

A common message that I have been hearing (and reading) is that serverless allows to concentrate on app business/logic. And that’s true. You write the code and the cloud platform simply runs your function, it ensures virtually unlimited scalability and you only pay when you function is running. No need to worry about servers, maintenance, deployment, etc.

As a side note, I find “allows to concentrate on app business/ logic” message interesting because every new technology/software/framework in the past had the same message.

AWS Lambda is the Leader

AWS Lambda is no doubt the leader in the serverless space right now. Probably because they were the first to introduce serverless on their cloud. I think most non-Amazon speakers mentioned or used AWS Lambda. They are closely followed by Microsoft with Azure Functions, then Google Cloud Functions and then IBM Cloud Functions.

Contaners vs. Functions

A number of talks mentioned containers vs functions. It’s not really one vs. the other. Functions are easier and give you higher abstraction. Containers give you more control and flexibility. It depends on the context and the problem you are trying to solve. In general this is how it looks:

Continue reading “What I Learned Attending a Serverless Conference” →

How to Pass Parameters to a Cloud Function

In my previous blog post I showed how to invoke an external REST API from a cloud function. The API that I used returns a random (Chuck Norris 💪) joke. In this blog post I want to show you to how pass a parameter to the cloud function. We can pass a joke number to the API and get that particular joke back 🤣.

Using the code from the previous blog post:

var request = require("request");

function main(params) {
   var options = {
      url: "https://api.icndb.com/jokes/random",
      json: true
   };

   return new Promise(function (resolve, reject) {
      request(options, function (err, resp) {
         if (err) {
            console.log(err);
            return reject({err: err});
         }
      return resolve({joke:resp.body.value.joke});
      });
   });
}

to get a particular joke number, change the URL to look like this:

url: "https://api.icndb.com/jokes/" + params.joke

params – passed to main function is a JSON object that holds parameters (input) to this cloud function.

Continue reading “How to Pass Parameters to a Cloud Function” →

How to Invoke an External REST API from a Cloud Function

In a previous blog post I showed how to create your first cloud function (plus a video). It’s very likely that your cloud function will need to invoke an external REST API. The following tutorial will show you how to create such function (it’s very easy).

  1. Sign into an IBM Cloud account
  2. Click Catalog
  3. Remove the label:lite filter and type functions
  4. Click on Functions box
  5. Click Start Creating button
  6. Click Create Action
  7. For Action Name enter ajoke and click the Create button.  A new cloud function will be created with Hello World message
  8. Replace the function code with the following code which invokes a 3rd party REST API which returns a random joke: 
    var request = require("request");

function main(params) {
   var options = {
      url: "https://api.icndb.com/jokes/random",
      json: true
   };

   return new Promise(function (resolve, reject) {
      request(options, function (err, resp) {
         if (err) {
            console.log(err);
            return reject({err: err});
         }
      return resolve({joke:resp.body.value.joke});
      });
   });
}
    • The code is simple. It uses the request Node.js package to connect to an external REST API
    • The external REST API returns a random joke
    • A JavaScript Promise is used for invoking the REST API
    • At the end the cloud function returns a response in JSON format
  9. Now click the Save button to save the code. Once the code is saved the button will change to Invoke. Click the button to invoke the function. In the right-hand panel you should see output with a random joke: 
    {
  "joke": "Project managers never ask Chuck Norris for estimations... ever."
}

This is how it looks inside the IBM Cloud Functions editor:

cloudfunctions-invoke-restapi
Cloud function code

Of course you can also build and test a cloud function using the CLI. I’ll cover that in another blog post.

Continue reading “How to Invoke an External REST API from a Cloud Function” →

6-Part Online Meetup Series On How Technology Can Help With Natural Disasters

We are launching a 6-part online meetup series where we will cover technologies and solutions that can greatly help before, during and after a natural disaster. In fact, this webinar series is a part of Call for Code initiative headed by IBM, The Linux Foundation, UN Human Rights, and American Red Cross.

The online meetups are only 30 minutes. If you are up to answering the call and would like to participate in the challenge, the online meetups will cover available resources to help you get started fast and build a solution. Join our online meetups regardless as they fun and educational.

  • Evaluate Person’s Pulse Data with Machine Learning 
    • Wednesday, August 8, 9:30am Pacific Time
    • Register
  • Learn How to Create and Analyze Charts, Graphs, and Maps
    • Thursday, August 9, 9:30am Pacific Time
    • Register
  • Learn How to Add Visual Recognition to an iOS App
    • Wednesday, August 15, 9:30am Pacific Time
    • Register
  • Translate Written Communications to Improve Information Sharing
    • Wednesday, August 22, 9:30am PT
    • Register
  • Build a cellular IoT Asset Tracker with Blockchain
    • Thursday, August 29, 9:30am Pacific Time
    • Register
  • Build Financial Networks with Blockchain to Execute Secure Transactions
    • Wednesday, September 5, 9:30am Pacific Time
    • Register

Video: Build Your First Cloud Function

Last week I showed you how to build your first cloud function using IBM Cloud Functions. I also recorded a 5-minute video that shows how to build your first function and a number of ways to invoke it via a REST API. Check it out below and let me know what you think.