Why a developer should not care about Serverless
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.