Search This Blog

May 6, 2020

6 Strategies For Migrating To AWS - A Cheatsheet

Migration to cloud is no easy task. There are a lot of planning and preparation that needs to be done before the journey even begins. But this post is not about the phases of cloud migration. 

This post is about the common strategies that are adopted by the organisations to migrate applications from on-premise to cloud. This post is not a substitute to the AWS Whitepaper on this subject, but an exam cram or cheat-sheet of sorts to aid your understanding and remember it all easily. So the cheat-sheet to 6 common strategies are:

1. Re-host

  • Think: Lift and Shift 
  • Times when you can automate the entire migration by way of automation with AWS Server Migration Service (SMS), without much manual intervention.

2. Re-platform

  • Think: Lift, Tinker and Shift 
  • Times when you take the migration as an opportunity to tinker your platform for good. Typical use case is to leverage AWS Managed Services to reduce the maintenance overheads, like using AWS Relational Database Service (RDS) in cloud. The engine is same, the platform is different. This should be analogous to situations when you use the same car for driving on icy-roads or dry-roads; just that you may tinker your car tyres with snow-chains for better friction on snow-filled roads.

3. Refactor / Re-Architect

  • Think: Re-modelling for better
  • Times when you refactor and/or re-architect your app in a fairly big way. Typical use case is to go cloud-native leveraging Elastic Kubernetes Service (EKS) or Elastic Container Services (ECS) by re-factoring your monolithic app as a set of microservices. Enterprises might adopt this strategy even if this is an expensive approach, should they deem the benefits out-weight the costs.

4. Re-purchase

  • Think: Drop and Shop
  • Times when the enterprises mimic individual shopping habits, like how we simply discard our current mobile phone for the newly launched mobile phone offering promising features. Or think of how we discard our current car for a new one. Ok that might be a stretch to think of all migrations choosing this strategy. There are umpteen occasions when this is a clear winner. Think of use-cases where:
    • Companies dropped in-house and/or disparate office tools and adopt Zoho Office Suite, because they find it fairly economical SAAS offering.
    • Companies dropped in-house code-repository service and adopt Github for good.
    • Companies dropped in-house and/or disparate Continuous-Integration/Continuous-Deployment (CI/CD) ecosystem to adopting AWS CodePipeline (which can deploy apps even on instances running on-premise!)

5. Retain

  • Think: Revisit later! 
  • Times when you wouldn't want to taunt the beast, like when you have mainframes systems that are managed on-premise. You know it's a beast out there that requires to be handled with great focus and deliberations. After all, you don't want to be mauled, do you?

6. Retire

  • Think: Decommission 
  • Times when you discover legacy apps being maintained for no apparent business value add. We all have heard of this office gossip of how some office detective in sysops-team discovered an unused or hardly used app that was silently eating the server capacity. He had the audacity to put his neck out and flag this to the management. He first got reprimanded and only later was thanked and congratulated...oh, focusing on that poor application, its now decommissioned!

May 4, 2020

Pre-Warming AWS Lambda Functions

Do you know that if your Lambda function is not invoked for a while and then invoked later, it may not be as responsive as you would wish it be?

And that is because if a Lambda function is not used for a long time (which is subjective to AWS systems as it deems right perhaps based on the demand against available capacity), AWS would re-cycle the container hosting the Lambda function. Subsequent to that for any new requests to this lambda function, AWS needs to deploy the container hosting it for the lambda function execution to happen. This overhead time of launching the container will make your new requests look a little unresponsive.

This can potentially be an issue that might surprise your team and business alike when you least expect it. To avoid such unpleasant and unwanted surprises, you can keep the container active discouraging it to be recycled by AWS infrastructure systems. AWS calls this technique as pre-warming the lambda function.

But what is the best way to put this technique in practice? In order to pre-warm the lamnda function, the best way is to call it using a schedule.

"If schedule, then AWS CloudWatch". Did your mind ring that?

AWS implements scheduling as an event source type (aka triggers) via CloudWatch Events. You can now invoke a Lambda function on a regular, scheduled basis. You can specify a fixed rate (number of minutes, hours, or days between invocations) or you can specify a Cron-like expression. In our case, we can configure a CloudWatch Event rule and select the lambda function as its target. The event is executed every minute to warm up the function so that the function stays active.

You can define this trigger:
  1. for a new lambda function at the time of defining it from Lambda Console like below:

  2. for an existing lambda function that is already deployed from Lambda Console like below:

  3. for an existing lambda function that is already deployed from CloudWatch Management Console like below:
Hope that helps!

May 1, 2020

My Experience With Pluralsight E-Learning Platform

In my earlier blog post I have shared my experience of how I could make surprisingly good use of Pluralsight's FREE April subscription, in the hope that others might draw similar mileage in times of Covid-19 pandemic uncertainty.

Now in this blog post, I'd like to continue on that and share my experience of Pluralsight platform. I had earlier used this platform sitting alongside my team members to encourage online learning in teams that I coached and consulted with. Unfortunately, I didn't explore it much back then to motivate my teams. I hope the earlier post and this one serves them well as much as I hope it serves you :)

What really clicked for me?

  • I really love the Skill IQ tests. It is not too lengthy and not too short. Most of the questions are good with custom time ticking. Check out my Pluralsight Profile for the number of tests that I took during April 2020.
  • The conferences addition is a good one. I book-marked a few but couldn't complete it all.
  • The user profile page is motivating to learn more and more. I happened to discover it mid way through the month prompting me to take more tests. It surely gamefied my experience.
  • I personally like the way learning path is crafted, although I didn't go that way during this FREE month offering.

Some of the courses I would recommend at Pluralsight

Some Authors I follow at Pluralsight

What I would wish from Pluralsight?

  • It has come a long way  from being more of a Microsoft shop. It still is in my opinion. Make it much more diverse in tech. 
  • Make it a go to place for courses related to certifications like that of AWS, Kafka, etc. This one is super competitive today, but is well worth pursuing.
  • While most questions in Skill Iq were good, there were some that lacked clarity given the dynamic time to answer that question. I tried giving my feedback on quite a few questions but got no acknowledgement or response from Pluralsight. I don't know if they have a team that is going to look into it. Wish it is a little responsive to feedback to build that affinity.
  • Okay I see Pluralsight has its own branding in the way courses are organised and structured. But I think it will be more fun to have other brands on boarded too like how O'Reilly did with Safari Online.
  • It will be super awesome to have ebooks too on this platform.
  • It will be great to have sandboxes like KataKoda for interactive learning.
  • Onboard popular authors from other platforms to have their courses in Pluralsight as well. Some of the popular authors include Stephane Maarek (for AWS), Maximilian Schwarzmuller (for ReactJS), Mumshad Mannambeth (for Kubernetes) etc.
  • Have Learning Paths tailored to Certifications and Technology. During one of my consulting stints, I was trying assemble a list of courses to help my teams go through it for Azure cloud and Kubernetes.
  • Make it more individual friendly when it comes to pricing. 

April 24, 2020

Making the best use of Pluralsight's Free April subscription

Pluralsight motivating people to skillup during Covid19 pandemic.
At a time when the busy world became near stand-still and extremely stressed on every count, when Covid19 clouded the lives to darkness, there arose a leader from that very darkness announcing its decision to offer all of its 7000+ courses for FREE in the month of April 2020, motivating a lot of people to Stay Home and Skill Up (and flatten the Covid19 curve). By the way, that is Pluralsight for you!!..
Thank you Pluralsight, I'm one of your millions/billions of beneficiaries.
With that note of thanks to Pluralsight, I'd like to share how I motivated myself and benefited from it, so that you too can. It never is too late, given that you have a week more left.

Paths, Channels and Bookmarks

Pluralsight has a nice way of chartering Paths with 3 distinct levels - Beginner, Intermediate and Advanced. I explored this and gazed this for a while leaving me with a choice list of many paths that I wanted to explore :(

I then went on to search courses by my topics of interest like AWS, ReactJS, ES6 etc wanting to refresh my knowledge. This led to adding select courses from search results to my newly created Channel by name Favourites. While I could create a channel topic wise, I added them all to single channel that could act as my TODO list.

But even as I was doing this, I slipped onto Bookmark-ing courses of interest. After a couple of days, I realised I have two TODO lists with lots of courses in it. And that is so discouraging, damn it!

And Skill IQs caught my attention...

Start with Skill IQs

I kick-started to action with Skill IQ tests. These tests are good and post tests it shows your skill gaps with related courses. These related courses should prod you to learn give those a shot, at least it did that for me :)
Skill IQ's Assessment Details

You just feel young and refreshed taking one test after another irrespective of the score, for one, the tests are not too lengthy and exhaustive. They contain approximately 20 multiple choice questions. See below some of my Skill IQs:
Skill IQs

I wish I had spent much more time with it..and I hope to make better use of it in this last week. You too can benefit from Pluralsight, after all April isn't over yet and it's never too late until this month ends :)

Now that is how I got motivated to stay home and stay skilled up. Your mileage may vary. But that shouldn't stop you to try right?

Note: I have not been an employee of Pluralsight nor was associated with its business in any rights so far. I'm just an accidental user by virtue of their #FreeApril advertisement. So if you haven't tried this platform yet, I think you should today, for you have not a penny to loose from it... what say?

Got your story to share and motivate? Do share it here to help me learn from you. Thanks in advance!

April 23, 2020

Advice for Startups adopting AWS Cloud : Part 1

Image Credits:

Are you a startup? Got a lean and mean team of developers wanting to deploy your apps in AWS Cloud? Are you cost conscious?

Unless you are a sysops yourself and that you are at home with AWS cloud, don't use IaaS of AWS; instead use PaaS of AWS.

And that means don't try to deploy your apps on EC2 by setting up your own VPC and configuring a whole suite of things. Instead make use of AWS BeanStalk. And there again, make sure you don't tie your RDS with your environment life-cycle, when it comes to production environment.

Overlook this advice, and your startup could end-up in the list of those that died before they were launched. This advice holds good if you don't have an exclusive #SysOpsAdmin for #Cloud. If you cut your costs here, you will end up burning your back to say the least.

A tad bit more details:

If application development is one kind of a beast, managing infrastructure is altogether another kind. I have come across many founders that under-estimate tech challenges calling it as not being a rocket-science in spite of going through mounting challenges blaming it on the dev-team. Little do they know that the developer-ego is bigger than that of a founder-ego, and so (s)he will call the infrastructure management an easy-peasy thing. The catastrophic effect of this is that the team ends up embracing cloud as IaaS provider. Without knowing the contemporary better-practices, they end up leaving gaping holes in the system to be exploited by a hacker and thus receiving a shocking monthly bill from AWS. There is no point blaming AWS as being pricey hiding your idiocy.

So here is my first-principle that should be yours as well when it comes to making technology decisions: Your choice of technology (be it the platform, the programming language, the architecture, the tools or even the framework) should be a reflection of your team's strength.

Let me say it louder again,
Your choice of technology should be a reflection of your team's strength.
So a recipe that comes out of that first-principle in this situation would be:
If you got a SysAdmin embrace Iaas, else be wise enough to embrace PaaS.
Further motivation for your prosperity: With IaaS, you end up managing 5 ever-evolving parts. With PaaS you will end up managing just 2 ever-evolving parts. For the moving parts, see the article banner picture.