Heartin Kanikathottu

Author
+ Follow
since Oct 25, 2009
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Heartin Kanikathottu

Congratulations to all the Winners. I will continue to be around this form and will try to answer questions on serverless or AWS cloud whenever possible.

M Khalid wrote:Hi,

I have read tech blogs regarding Serverless Programming.
Is this book releated to basic Programming or Advanced level?

Thanks and All the best for the book



Regarding programming skills basic Java is good to have as AWS Lambda recipes uses Java runtime. Even though the book explains all Java setup required, the book does not teach Java. That said, most other recipes uses AWS CLI and/or cloud formation and hence are programming language independent. You can implement the APIs and flow with any programming language you prefer. And with respect to AWS, it starts from the basics and assumes no prior knowledge.

Liutauras Vilda wrote:Welcome to the ranch, Heartin Kanikathottu,

I have a question. Either on AWS or Google Cloud, in particular lambdas and cloud functions, you can write them using a certain set of languages, mainly: Go, Java, JavaScript, Python. So my question is, in cloud environments, are there any known significant differences, why one language would be better over the other to use specifically in cloud environment, or they are purely just for the variety purpose? Or maybe it is a standard model, which is very much related with the "use tool which fits the task best"? Thanks.


Selection of runtime may some impact on cold start times. JavaScript or Python may have lesser cold start time compared to Java. Also, if you are building a web app with a JavaScript based front end, you may prefer JavaScript. Similarly, if you are working on a machine learning project, you may select Python because of its libraries. However, in most cases it is decided based on your team's knowledge level. If you have a team of Java developers you will most probably develop in Java as long as all of the required functionality can be met using that runtime. AWS Lambda now even support custom runtimes. So you are no more restricted to few predefined runtimes.  

Liutauras Vilda wrote:Heartin Kanikathottu, welcome to the Ranch! Have a great book intro week.



Thank you. Hoping to answer most questions related to book or serverless in general and learn some new things as well.

Asif Haciyev wrote:Hi
Heartin, I want to know when is the right time to start reading this book? I mean what are the prerequisites? I have learned Java SE and now I am beginner in Java EE. Could you provide me roadmap to reach this book?



The book is for people with no prior knowledge of AWS and starts with AWS account creation. But some knowledge of Java is good to have since I have used Java as the programming language to write AWS Lambdas (you already have that knowledge as you have mentioned). That said, most other recipes use either AWS CLI commands or CloudFormation templates and is programming language independent. You can implement the APIs and flows in any programming language you are comfortable. Enough theory is provided with most recipes (including HTTP and REST essentials). Book covers following AWS components from basics or as a continuation of previous recipes: AWS Lambda for FaaS, DynamoDB for backend, API Gateway for REST APIs, Cognito for user management, Route 53 for DNS management and domain registration, CloudFront fo CDN, AWS Certificate Manager for Certificate generation, S3 for static website hosting, SNS for notifications, SQS for messaging, Kinesis for data streams, Amazon ML for ML, Alexa for NLP and CloudWatch for monitoring. Finally, the book also gives you getting started guides for FaaS in Azure, Google Cloud and IBM Cloud. Even after all this if you need further help, I am always available to help on any queries through Linkedin / my blog. For beginners who come to me with a little or no programming language experience, I even provide a welcome kit with enough support materials (and previously answered questions) to get started. As I mentioned in another post, I believe that my responsibilities as an author in not over after publishing the book.

Adriana Vargas wrote:Very interesting and relevant topic.

Best luck with the book !!!





Thank you..

And let me know if you need any support with the book or serverelss. I believe that publishing a book is just the beginning of my duties as an author. There are readers asking me questions regarding the contents within book through my websites or Linkedin.

sourabh girdhar wrote:Welcome Heartin,
Best of luck for your book.. apt topic as it is the latest trend in technology.


Thank you...

Campbell Ritchie wrote:Welcome Good to see you here; I hope you get lots of nteresting questions.


Thank you

Lucian Revnic wrote:Hello,

Welcome to The Ranch!

Are Serverless technologies considered to be production ready by enterprise companies?
I see many challenges such as testing serverless apps, security of serverless apps, sharing common code across functions inside apps etc that seems to not be fully addressed yet by the vendors.

What is your perspective on these?

Thank you,
Lucian R.



I believe so... As mentioned in another post, Serverless services are mostly vendor dependent. Not all vendors may be on the same level with respect to serverless capabilities. I work extensively on AWS platform and can provide some examples. I also know many companies that use AWS services such as AWS Lambda, Amazon DynamoDB, Amazon S3 etc. in production applications extensively. AWS has recently introduced a feature called Lambda Layers, which should solve your code sharing concern to some level. You may also refer to Amazon SAM Local for local testing of your serverless applications. AWS also has networking and security features like VPCs that you can use with your serverless apps. Other providers will also have similar services and functionalities. Let me know if I answered your question correctly.

Lanny Gilbert wrote:Actually, a couple of questions  

1.) Does your book cover how to take an app that is running successfully in a K8S environment and move it to AWS (or other) platform for serverless execution?
2.) If not, what advice would you give to move a K8S app to serverless? Actually, your advice is welcome whether it's in the book or not.

Thanks!


1) Sorry, the book does not cover Kubernetes related recipes. The book covers most of the important serverless / fully managed services within AWS, and even looks into FaaS within Azure and Google Cloud. I wish I included some recipes on containerization, but the pages already came close to 500 and the original target was 400.
2) Regarding moving K8s app to serverless, I assume you are referring to serverless container orchestration. One thing to note is that Serverless services in general are cloud-provider specific and each of them will have their own migration path. Amazon's solution to serverless container orchestration is AWS Fargate. AWS now even has EKS which is effectively K8s as a service. Google has announced Google Run which is Google's answer to serverless containers and runs on Google's version of K8s. However, first you need to decide if you are ok with vendor-lockin with the advantage of less maintenance efforts or want a generic one like K8s with bit more maintenance efforts. Anyway Google's serverless solution is based on K8s. Did I answer your question correctly?

Billy Tsai wrote:I also want to ask the author that does the book cover FaaS & BaaS? what are some frameworks we can use with Mesos Marathon, K8 to achieve those, I know AWS has Lambda, what about Azure and Google Cloud?



Regarding what the book will cover, first 5 chapters will cover all AWS services required to build a complete web application with a SPA front end, including registering domains and managing DNS. This includes AWS Lambda which can be considered FaaS and DynamoDB which can be considered a fully managed backend, Cognito for managing users, S3, Route 53, CloudFront etc. Second half of the book cover various other services that can complement the core services such as messaging, notifications, machine learning, natural language processing, monitoring etc. Regarding your question on Mesos Marathon, K8, each cloud provider will have their own preferences. For example, with AWS you might want to look at something like AWS Fargate for managing docker containers. Regarding your question on Azure and Google Cloud, the last chapter focuses on serverless services in other clouds such as Azure, Google Cloud and IBM cloud. It has hands-on recipes for FaaS equivalents to Lambda and lists down services that correspond to various other AWS services that were discussed in other chapters. Please feel free to ask if you need more clarity on anything I described.

sourabh girdhar wrote:Hi Heartin,

Generally people get confused that you need to have functional programs to run in server-less architecture. Also there are few scenarios where server-less may not be apt.
What's your view on these two topics ?

Does you book cover about how to think about designing applications to be server-less ?



Let us first discuss your question on the usage of functional programs. There was a general trend of considering serverless as only Function as a Service (FaaS). I would like to consider serverless architecture as an architecture where you do not have to worry about servers. It may involve writing code (functions), developing a backend, developing APIs, deploying your Single Page Applications (SPA), managing users and more. Technically your program need not follow pure functional programming style. You can write any code that will be compiled by the runtime you choose. However, a good understanding of the functional programming practices like avoiding state-change and mutable data, can help you write effective functions. You can create serverless applications without writing any code if your cloud provider give you enough abstractions.

For your question on when not to use Serverless, I want to share my opinion that serverless is not always a silver bullet for all use cases. Also, keep in mind that, in many cases serverless applications may have a tight vendor dependency. This is more true if you are using more serverless functionality from your cloud provider than just code like backend, APIs, managing users etc. So if you do not like vendor dependency don't go that deep into serverless. Also, serverless is generally preferred for applications with short-running requests with more idle times. If you have an application with long running services with no idle time, serverless might not be a good fit in most cases. That said, if you are ok with vendor dependency there might be workarounds in the form of vendor specific patterns / practices / services.

Regarding your question on whether the book will make you think serverless, upto some extend it does as it will show you how not to worry about managing any servers (or software) while building various component of an end to end application. That said, please note that this is a Cookbook and contains recipes for most common serverless use cases. Like any recipe based book, this book focusses on the "how" part more and less on the "what" part. There is however enough supporting theory for each recipe. Book is intended for people who want to get solutions for their problems or for people who like to get their hands dirty first and then learn the related theory.
Thanks Mike...

My requirement had initially said to use MDB for receiving request and JMS Template for sending back response. I believe there are some performance difference between MDB and MDP.

Anyway I will look into this and get back...
10 years ago
Thanks for the quick reply.

My real name is Heartin Jacob Kanikathottu ( visit www.heartin.in for my original profile ) Anyway I have updated my name to Heartin Kanikathottu.

Yes, I will be using Spring Framework for setting up my service and repository/dao classes for the business logic that is not related to the UI or transport layer being used. But I should put only getting data related things in service layer and put business logic in domain layer right?

Also not clear on how other pieces will fit together.

I will make things more clear.

We have a current MQ based ejb application that has an MDB getting the xml request, give the request to a handler and then the handler decides which java class to call based on a parameter. This specific java class will then get data from backend, create response xml and send it back.

My new requirement has to implement the same with below constraints.

1. Need to use message driven beans ( MDB ) for getting data.
2. Need to use spring JDBC template for getting data from backend in form of hash maps.
3. Need to create response xml by populating data from that hash maps.
3. Need to use JMS template for sending data back.

I don't want to use web service here as it is MQ based. So what is the best solution for an MQ based application mentiones above.

Any help is highly appreciated.
10 years ago
Could anyone help me in deciding the best approach for implementing an application as below:

A request ( xml ) is provided to a handler, which calls specific java class, which inturn get data from backend and prepare the reponse xml and send it back ( xml ). I need to know how I can organise this app into controller, domain and service layers. Siince there is no jsp I believe we won't have a view.

The request xml will be recieved by an MDB and the response xml will be sent back using JMS template.
10 years ago