Why a developer should not care about Serverless
Being a developer, one should be least bothered about Serverless. Why? Serverless is big bet and Gartner says "" etc. So what? Ask some basic questions to yourself, if Serverless going to reduce the coding effort? Those sleepless nights where you had debugged a thousand line JavaScript file with alert('1'), alert('function worked fine') etc. The answer is undoubtedly "No". Then what you should worry about. Being relevant to what is coming tomorrow. A truck driver is a truck driver in a silky-smooth highway vs mud roads. At the end of the day he needs to drive to his destination no matter how the road is with one condition - destination is reachable. The same analogy applies with developers too. If a thing is doable it is doable no matter what runtime and framework you use, whether you deploy to cloud or on-premises, it remains the same. Stick to few basic things,
Select the right programming language: Your selection of programming language matters. It matters with how much time you want to invest on this, what is the available skillset within a team. If this is mature enough to handle the workload. Just by going what is up there in market may not be a wise decision. It should come from the experience and reliability.
SOA is the key: SOA has been a decade old reality, and it still applies. With all the buzzwords like Microservices, Serverless it falls under same good old bucket of SOA. Be it Monolith Apps, Nano-Services, Microservices all are the here to solve your business problem. Don't fall in love with one and show as loyal to that. It doesn't help being a fundamentalist.
HTTP is the winner: Many types of applications came and go but still today Http is the clear winner. Because of its simplicity. No matter how rich your user interface is - fails to appeal if every client is maintained separately. It is not just scalable. When someone loves an application, but it works only on device it does not have a many user for a very long period of time. Instead of building phone based applications which is no way cheaper to make and maintain, use the adaptive UI design to work seamless in all kind of browsers makes one's life simple.
Logging is super important: No one cares about a doctor unless he/she is ill. And after you reach doctor and say a hi to him the first thing he asks is your diagnosis reports. Same with the Apps. An App which is running fine and no one cares about its wellbeing. But when it does not then those diagnostic logs are important. The server where an app is deployed or the web server it is hosted captures the event by default, but it is not enough. Does it retrospect the intermittent issues? Can you identify the complex workflow? You need a deeper insight. So, opening up an application code level logs are very important. Because at times unhandled exceptions are visible but when your internal logic fails, having a code level log helps fix it quickly.
Polyglot persistence: In today's world one-size-fits-all does not apply anymore. Select the data source wisely. You don't need to select one data source for your whole application. There are a wide variety of data sources available from different vendors specialized on one aspect of application functionality. Like a relational database is definitely not a right selection for storing video files if your application is an online streaming portal. My experience is select more than one type of data source. If your application has one data source, then it's time to redesign.
Dependency injection: Did you use it? If not, then fall back to it. Nothing like it.
Domain-Driven-Design and Repository Patterns are live savers: It is easy to compare project without them with the project having them as part of the DNA. One simple outcome is "manageability".
Last but not the least is "Security" - with openness applications going to cloud this is no more a "good to have" feature. Your design thinking should start from the groundwork of security.
Namoskar!!!