Before you start, you need to understand what you’re building and why.  Then you can choose from a selection of best-fit technologies from the CDP Eco Template Catalog.  Look for all of the templates (seeds) on the Use CDP page, under the "ECO Seeds" column.

 

When selecting technology to use for your microService, consider a few factors.  You often run into multiple good choices instead of one “best” one, and any tech you pick could have deficiencies that you’ll have to manage. So you’ll want to choose a manageable and long-term usable technology that meets the most important goals.        .

Identify your hardest problem(s), and only consider solutions that can solve them.  Using a technology that can’t help solve the hardest problem wouldn’t make sense.

The hardest problems for applications vary based on what they need to do, how they’re used, and the functional and non-functional requirements placed on them. Requirements could include performance, capacity, usability, availability of knowledgeable developers, adoption, open-source contributions, and more.

Industry trends are important because they showcase new developments, ideas, and approaches. They should be understood and adapted to the needs of AT&T.  Not all are sustainable; don’t accept a new trend/technology on face value without the required analysis of how it applies to AT&T.  However, non-sustainable or short-lived trends may still provide valuable insight into ways to improve our processes and the technologies we use.

No two software products are exactly alike. They always have differences in requirements, deployments, operational environments, user and developer communities, and more.  Don’t risk using someone else’s technology choice without research and analysis of what you need first.  Just because XYZ worked for Joe doesn’t mean it will work for you.  More importantly, it could make you overlook selections that would work better.  Without doing the analysis, you would not know.

Be agile when selecting technologies, especially early in product development.  Instead of focusing on one technology, choose a few candidates.  Experiment with and prototype the project’s most difficult or risky areas and learn which technologies will work best.  Even after you decide, avoid getting so locked into that technology that you can’t change.  Unforeseen situations like new requirements, business demands, and market shifts may force you to.  Making it as easy on yourself as possible will make the changes easier and cheaper.

No matter what you choose, the product must be developed, tested, packaged, deployed, and supported.  Consider the resources that you have that can do these tasks.  Choosing a cool new tech may make you happy, but if we can’t get developers to build it at a reasonable cost and speed, then it’s not a good strategic choice for the company. 

Keep non-functional requirements in mind, especially strict performance and scalability requirements.  They may dictate specific design approaches like stateless and idempotent services, and can place higher demands on back-end technologies like data stores and caching.  These cascading requirements create dependencies between the application’s different parts, and may require different design approaches and different technology selection.

Nothing is free!  Even open-source software has costs associated with it.  So does project management, development, testing, packaging, deployment, monitoring and support.  Identify what each of these needs for each selected technology, and find the total cost (initially as well as recurring).  Choose technologies that can lower costs while improving these processes.

Despite how much open-source exists and how incredibly fast it’s growing, few of these products will get widespread adoption and support from the community.  Someone might publish the best widget ever conceived, but it should be viewed carefully if it can’t get community backing.  Open-source comes with the benefit of wide community support of a product that helps us in the long term.  So if you choose an open-source product with a small or inactive community, you take on the risk of supporting and extending that code, thus increasing cost and risk.  In general, we should avoid this.  You can usually find alternatives with much better support that will help mitigate risks and lower costs.

Be very careful selecting open-source products for your project.  Not all of their licenses are equal!  Beware of licenses that require you to publish your source code when you include the library.  In general, you should not use licenses like the GPL.  The LGPL (Lesser Gnu Public License) doesn’t require you to disclose your source code and lets you include the library in your product if you don’t modify the code or derive works from it.  However, every license must be inspected and if in doubt, get help from AT&T legal in choosing the correct licenses. 

Don’t do it alone.  Talk to people who have experience with a wide set of technologies.  Widen your view; don’t focus on one specific technology early on.  The old saying, “If you’re a hammer, everything looks like a nail,” applies in this case.  If you go into analysis with a preconceived bias towards a tech or approach, that’s all you’ll see.  Widen your view initially so you get the best possible set of choices.  Seek assistance from others who have experience with multiple technologies and projects.  Experience is the best teacher.