How content creates content

A big part of many developer advocacy programs is content. Content can be in the form of tutorials, blog posts, videos and hands-on workshops and other forms. Coming up with content ideas is not always easy. In this blog post I’m going to share some ideas how to simplify content creation.

The IBM Developer SF team hosts weekly events. We host at least one in-person event and one online event (webinar/online meetup). For every in-person workshop we host an online event. It’s usually best to host the online event after the in-person event as people who couldn’t make the in-person event can watch the online version (but the other way is also fine).  The in-person event is about two hours and the online event is usually 40 minutes.  So yes, the content covered will be different but the basis will be the same. This is the first example where doing a hands-on workshop easily creates content for an online event.  The in-person event doesn’t necessarily need to be a meetup/workshop type event. It can also be a conference talk, a panel or a Q&A. It can really be anything.

We we host our online events on Crowdcast, the event is automatically recorded and the recording is available a few minutes after the event is over. The video can be downloaded and uploaded to your YouTube channel. Right there you have another piece of content. You can also take the video and create a blog post with it. Embed the video in the blog post with a short description of what you covered. That’s another content idea.

Here is an example of how you can start:

content-creates-content-1

This is nice considering this all from a single content piece.

Continue reading “How content creates content” →

DevRel Q&A with Matthew Revell from Hoopy

I did a Q&A with Matthew Revell from Hoopy on Developer Advocacy.

Matthew: Tell me about your role at IBM.

Max: I joined IBM about a year and a half ago and work in the Developer Advocacy organization. I lead a wonderful team of Developer Advocates and we cover the North America West region. The majority of our time we spend in the San Francisco Bay Area. The team provides developer education and covers technologies such as Watson AI, Containers, Serverless, Blockchain, Node.js and Machine Learning.

We run weekly in-person and online developer education events in the San Francisco Bay Area. We love to partner with other companies and organizations such as Women Who Code, Hacker Dojo, and others to host joint events. This works extremely well for us. We also attend and speak at local conferences and publish content such as tutorial, how-to’s, and videos.

Matthew: What brought you to this point in your career?

Read the rest of the Q&A.

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” →