\u00c9 precisamente aqui que entram as Azure Functions<\/strong>: uma solu\u00e7\u00e3o de computa\u00e7\u00e3o serverless<\/em> do Microsoft Azure que permite executar blocos de c\u00f3digo de forma simples, escal\u00e1vel e sem a necessidade de gerir servidores ou infraestrutura.<\/p>\n\n\n\n As Azure Functions destacam-se por reduzirem a complexidade ao eliminar a necessidade de gerir servidores, uma vez que toda a infraestrutura \u00e9 gerida automaticamente pelo Azure. As Azure Functions permitem desenvolver aplica\u00e7\u00f5es ou micro-servi\u00e7os leves, modulares e escal\u00e1veis, tendo por base eventos como pedidos HTTP, altera\u00e7\u00f5es em bases de dados, mensagens em filas de espera ou tarefas agendadas. Al\u00e9m disso, permitem a integra\u00e7\u00e3o com outros servi\u00e7os do ecossistema Azure e com APIs externas suportando v\u00e1rias linguagens de programa\u00e7\u00e3o como C#, JavaScript e Python, facilitando assim a adapta\u00e7\u00e3o por parte das equipas de desenvolvimento.<\/p>\n\n\n\n No contexto do desenvolvimento das Azure Functions recorrendo-se \u00e0 programa\u00e7\u00e3o em Python, o c\u00f3digo \u00e9 criado localmente com ferramentas como Visual Studio Code, PyCharm ou atrav\u00e9s do terminal (atrav\u00e9s das Azure Functions Core Tools), sendo posteriormente publicado na cloud da Azure.<\/p>\n\n\n\n A integra\u00e7\u00e3o nativa com plataformas como GitHub, Azure DevOps ou GitLab assegura um fluxo cont\u00ednuo de desenvolvimento, testes e publica\u00e7\u00e3o. A utiliza\u00e7\u00e3o de pipelines<\/em> de CI\/CD (processos que integram, testam e entregam c\u00f3digo de forma cont\u00ednua) facilita a automatiza\u00e7\u00e3o de tarefas essenciais, desde a verifica\u00e7\u00e3o at\u00e9 \u00e0 publica\u00e7\u00e3o das vers\u00f5es atualizadas, garantindo assim maior consist\u00eancia e rapidez.<\/p>\n\n\n\n Paralelamente, o Azure recolhe logs<\/em> e m\u00e9tricas em tempo real, fornecendo visibilidade total sobre o comportamento das fun\u00e7\u00f5es, o que simplifica significativamente a monitoriza\u00e7\u00e3o e o diagn\u00f3stico de problemas.<\/p>\n\n\n\n O desenvolvimento de Azure Functions em Python pode seguir dois modelos principais: o v1 e o v2. O modelo v1, mais antigo, \u00e9 baseado no .NET Framework, uma tecnologia dependente do sistema operativo Windows, e recorre fortemente a ficheiros de configura\u00e7\u00e3o externos, como o function.json <\/mark>resultando numa menor integra\u00e7\u00e3o entre configura\u00e7\u00e3o e c\u00f3digo.<\/p>\n\n\n\n Por outro lado, o modelo v2 apresenta uma abordagem mais moderna e centrada no c\u00f3digo, permitindo definir fun\u00e7\u00f5es diretamente atrav\u00e9s de m\u00e9todos \u201cmain<\/em>\u201d. Esta evolu\u00e7\u00e3o simplifica a estrutura dos projetos e proporciona uma melhor experi\u00eancia de desenvolvimento. A escolha entre os dois modelos deve ter em considera\u00e7\u00e3o fatores como a complexidade da aplica\u00e7\u00e3o, o grau de personaliza\u00e7\u00e3o necess\u00e1rio e a prefer\u00eancia por uma abordagem mais declarativa (v1) ou mais orientada ao c\u00f3digo (v2).<\/p>\n\n\n\n No Modelo v1, cada fun\u00e7\u00e3o \u00e9 implementada numa pasta pr\u00f3pria, contendo dois ficheiros principais: o ficheiro __init.py__<\/mark>, onde est\u00e1 escrita a l\u00f3gica da fun\u00e7\u00e3o em Python, e o ficheiro function.json<\/mark>, que define a configura\u00e7\u00e3o da fun\u00e7\u00e3o, nomeadamente os triggers<\/em> and bindings<\/em>.<\/p>\n\n\n\n Segue-se uma estrutura t\u00edpica de um projeto com o Modelo v1:<\/p>\n\n\n\n O exemplo seguinte ilustra como implementar uma fun\u00e7\u00e3o HTTP simples no Modelo v1, apresentando de forma clara a implementa\u00e7\u00e3o do c\u00f3digo nos ficheiros __init.py__<\/mark><\/mark> and function.json<\/mark>.<\/p>\n\n\n\n Este modelo \u00e9 particularmente \u00fatil em prot\u00f3tipos ou projetos de pequena dimens\u00e3o, permitindo um desenvolvimento r\u00e1pido e simples, sobretudo quando a equipa de desenvolvimento \u00e9 reduzida e a estrutura do c\u00f3digo n\u00e3o exige uma modulariza\u00e7\u00e3o complexa.<\/p>\n\n\n\n Contudo, \u00e0 medida que a complexidade do projeto aumenta, ou seja, com m\u00faltiplas fun\u00e7\u00f5es, l\u00f3gica partilhada e testes autom\u00e1ticos, o Modelo v1 pode revelar-se limitado. Nesses casos, recomenda-se a utiliza\u00e7\u00e3o o Modelo v2, que oferece uma arquitetura modular e escal\u00e1vel.<\/p>\n\n\n\n O segundo modelo surge como uma vers\u00e3o melhorada do Modelo v1 de forma a colmatar a insufici\u00eancia desta primeira vers\u00e3o do modelo face ao crescimento da complexidade dos projetos. Esta segunda vers\u00e3o simplifica a cria\u00e7\u00e3o de fun\u00e7\u00f5es, permitindo que m\u00faltiplas fun\u00e7\u00f5es coexistam num \u00fanico ficheiro Python. Neste modelo, os triggers<\/em> and bindings<\/em> s\u00e3o declarados diretamente no c\u00f3digo atrav\u00e9s de decorators<\/em>, eliminando a necessidade de ficheiros como function.json<\/mark> separados para cada fun\u00e7\u00e3o. Esta abordagem torna o projeto mais organizado e o c\u00f3digo mais leg\u00edvel, facilitando a manuten\u00e7\u00e3o do mesmo. \u00c9 poss\u00edvel observar no exemplo que se segue da estrutura do projeto, que todo o c\u00f3digo \u00e9 implementado no ficheiro function_app.py<\/mark>:<\/p>\n\n\n\n No exemplo seguinte, a fun\u00e7\u00e3o acionada por um Timer Trigger \u00e9 definida atrav\u00e9s de um decorator<\/em>, que especifica a sua agenda de execu\u00e7\u00e3o. Dentro da fun\u00e7\u00e3o main<\/mark>, implementa-se a l\u00f3gica que ser\u00e1 executada sempre que o trigger<\/em> dispara.<\/p>\n\n\n\n Utiliza-se logging.info()<\/mark> para registar mensagens nos logs<\/em>, uma pr\u00e1tica fundamental em aplica\u00e7\u00f5es serverless<\/em>, onde n\u00e3o existe uma interface direta para ver o output<\/em>. Os logs<\/em> permitem monitorizar a execu\u00e7\u00e3o, detetar erros e manter informa\u00e7\u00f5es de auditoria. Neste caso, cada disparo do Timer Trigger<\/em> regista a mensagem “Hello World! A fun\u00e7\u00e3o Timer Trigger foi executada.”<\/mark>, confirmando que a fun\u00e7\u00e3o correu corretamente.<\/p>\n\n\n\n Caso tenha por objetivo adicionar uma fun\u00e7\u00e3o, por exemplo, com HTTP Trigger<\/em>, a seguir \u00e9 poss\u00edvel observar como seria a implementa\u00e7\u00e3o da mesma:<\/p>\n\n\n\n Como \u00e9 poss\u00edvel analisar, as duas fun\u00e7\u00f5es s\u00e3o definidas no mesmo ficheiro, sendo cada uma independente e acionada pelo runtime<\/em> conforme o trigger<\/em> especificado. A fun\u00e7\u00e3o timer_main<\/mark> \u00e9 executada automaticamente a cada 5 minutos, registando uma mensagem nos logs<\/em>, enquanto a fun\u00e7\u00e3o http_main responde a pedidos HTTP, permitindo receber opcionalmente um par\u00e2metro name <\/mark>para personalizar a resposta. Esta abordagem simplifica a organiza\u00e7\u00e3o do c\u00f3digo e mostra como m\u00faltiplas fun\u00e7\u00f5es podem coexistir num \u00fanico ficheiro sem necessidade de um main <\/mark>central.<\/p>\n\n\n\n No Modelo V2 das Azure Functions em Python, os blueprints<\/em> constituem uma forma de modularizar e organizar fun\u00e7\u00f5es fora do n\u00facleo da aplica\u00e7\u00e3o. Um blueprint<\/em> \u00e9 uma classe que permite o registo independente das fun\u00e7\u00f5es, sendo posteriormente associado \u00e0 aplica\u00e7\u00e3o principal para que o runtime<\/em> as reconhe\u00e7a.<\/p>\n\n\n\n Os principais benef\u00edcios dos blueprints<\/em> incluem:<\/p>\n\n\n\n Segue-se uma representa\u00e7\u00e3o da estrutura de uma Azure Function desenvolvida com Blueprints.<\/p>\n\n\n\n A seguir est\u00e1 representado um Blueprint<\/em> simples, que cont\u00e9m uma fun\u00e7\u00e3o HTTP que responde a pedidos de rota \u2018\/hello\u2019.<\/p>\n\n\n\n http_blueprint.py<\/em> Aquando da defini\u00e7\u00e3o do Blueprint, \u00e9 necess\u00e1rio regist\u00e1-lo na aplica\u00e7\u00e3o principal para que as rotas fiquem acess\u00edveis pelo Azure Functions runtime<\/em>. O exemplo seguinte mostra como importar o m\u00f3dulo onde o Blueprint est\u00e1 definido e registar as fun\u00e7\u00f5es associadas ao mesmo numa inst\u00e2ncia da FunctionApp<\/mark>.<\/p>\n\n\n\n function_app.py<\/em><\/p>\n\n\n\n O Modelo v2 \u00e9 mais utilizado em projetos com m\u00faltiplas fun\u00e7\u00f5es e complexidade crescente. \u00c9 um modelo que traz vantagens especialmente para equipas maiores que precisam de trabalhar em paralelo e de organizar o c\u00f3digo de forma clara e modular. Este modelo \u00e9 tamb\u00e9m recomendado para aplica\u00e7\u00f5es que exigem escalabilidade e facilidade de manuten\u00e7\u00e3o, permitindo separar funcionalidades e responsabilidades em m\u00f3dulos distintos.<\/p>\n\n\n\n \u00c9 fundamental compreender as vantagens e limita\u00e7\u00f5es inerentes tanto \u00e0 utiliza\u00e7\u00e3o das Azure Functions como \u00e0 sua implementa\u00e7\u00e3o em Python, de modo a possibilitar uma tomada de decis\u00e3o informada e adequada aos requisitos t\u00e9cnicos do projeto.<\/p>\n\n\n\n A Azure Functions disponibiliza dois modelos de pagamento do tipo “Pay As You Go”: o Consumption Plan<\/strong>, que \u00e9 o modelo original, e o mais recente Flex Consumption Plan<\/strong>.<\/p>\n\n\n\n No Consumption Plan<\/strong>, o utilizador paga apenas pelo tempo de execu\u00e7\u00e3o e pelo n\u00famero total de execu\u00e7\u00f5es das fun\u00e7\u00f5es, beneficiando de uma oferta gratuita mensal de 1 milh\u00e3o de execu\u00e7\u00f5es<\/strong> and 400.000 GB-segundos<\/strong>. Este plano tem um limite de 1,5 GB de mem\u00f3ria por inst\u00e2ncia<\/strong> e o tempo m\u00e1ximo de execu\u00e7\u00e3o por fun\u00e7\u00e3o \u00e9, por defeito, de 5 minutos<\/strong>, podendo ser aumentado at\u00e9 10 minutos<\/strong> atrav\u00e9s de configura\u00e7\u00e3o.<\/p>\n\n\n\n Por outro lado, o Flex Consumption Plan<\/strong>, embora ligeiramente mais caro, oferece funcionalidades adicionais como inst\u00e2ncias sempre prontas (Always Ready<\/em>), maior flexibilidade na configura\u00e7\u00e3o da mem\u00f3ria e integra\u00e7\u00e3o com redes virtuais (VNET), sendo o plano recomendado pela Microsoft para cen\u00e1rios que exigem melhor desempenho e maior controlo sobre os recursos.<\/p>\n\n\n\n Na B2F foram desenvolvidos projetos que demonstram o valor desta abordagem, evidenciando n\u00e3o s\u00f3 o seu desempenho robusto e a flexibilidade intr\u00ednseca, como a capacidade de integrar, de forma simples e segura, in\u00fameras plataformas externas, nomeadamente atrav\u00e9s de REST APIs, para a execu\u00e7\u00e3o de processos ETL (Extract, Transform and Load).<\/p>\n\n\n\n Esta integra\u00e7\u00e3o flu\u00edda permitiu automatizar tarefas, interligar sistemas heterog\u00e9neos e impulsionar a transforma\u00e7\u00e3o digital de forma escal\u00e1vel, contribuindo de forma significativa para a redu\u00e7\u00e3o dos custos operacionais.<\/p>\n\n\n\n Investir em Azure Functions representa, assim, um passo decisivo para empresas que pretendem n\u00e3o apenas manter a competitividade, mas tamb\u00e9m ganhar agilidade operacional, reduzir custos com infraestruturas subutilizadas e acelerar o ciclo de inova\u00e7\u00e3o, transformando ideias em servi\u00e7os escal\u00e1veis de forma r\u00e1pida e eficiente.<\/p>\n\n\n\n Este \u00e9 o momento ideal para aproveitar todo o potencial das Azure Functions, contando com a Business to Future como parceiro estrat\u00e9gico na transforma\u00e7\u00e3o digital.<\/p>\n\n\n\n <\/p>","protected":false},"excerpt":{"rendered":" Num cen\u00e1rio em que as exig\u00eancias tecnol\u00f3gicas crescem de forma cont\u00ednua, as organiza\u00e7\u00f5es procuram solu\u00e7\u00f5es simples, eficientes e adapt\u00e1veis para responder a novos desafios. \u00c9 precisamente aqui que entram as Azure Functions: uma solu\u00e7\u00e3o de computa\u00e7\u00e3o serverless do Microsoft Azure que permite executar blocos de c\u00f3digo de forma simples, escal\u00e1vel e sem a necessidade de […]<\/p>","protected":false},"author":1,"featured_media":5593,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[94,97,95,96],"class_list":["post-5585","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business-intelligence","tag-azure-functions","tag-microsoft-azure","tag-python","tag-serverless"],"acf":[],"yoast_head":"\r\nOnde \u00e9 que as Azure Functions podem realmente fazer a diferen\u00e7a?<\/h1>\n\n\n\n
Python e Azure Functions: A Parceria Ideal para Solu\u00e7\u00f5es Inovadoras<\/h1>\n\n\n\n
Estruturas de programa\u00e7\u00e3o em Azure Functions<\/h1>\n\n\n\n
Modelo v1 vs. Modelo v2<\/h2>\n\n\n\n
Modelo v1<\/h2>\n\n\n\n
MyFunctionApp\/\n\u2502\u2500\u2500 host.json\n\u2502\u2500\u2500 local.settings.json\n\u2502\n\u251c\u2500\u2500 HttpTriggerFunction\/\n\u2502 \u251c\u2500\u2500 __init__.py\n\u2502 \u2514\u2500\u2500 function.json\n\u2502\n\u2514\u2500\u2500 XXXXXXXXFunction2\/\n \u251c\u2500\u2500 __init__.py\n \u2514\u2500\u2500 function.json<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/b2f.pt\/wp-content\/uploads\/2026\/02\/image-54-1024x466.png\")
<\/figure>\n\n\n\nModelo v2<\/h2>\n\n\n\n
\nMyFunctionApp\/\n\u2502\u2500\u2500 host.json\n\u2502\u2500\u2500 local.settings.json\n\u2502\u2500\u2500 function_app.py\n\u2502\u2500\u2500 requirements.txt<\/code><\/pre>\n\n\n\n\nimport azure.functions as func\nimport logging\n\n# Criar a Function App (obrigat\u00f3rio no V2)\napp = func.FunctionApp()\n\n# Fun\u00e7\u00e3o Timer Trigger no Modelo V2\n# Executa a cada 5 minutos\n@app.timer_trigger(schedule=\"0 *\/5 * * * *\", arg_name=\"mytimer\")\ndef timer_main(mytimer: func.TimerRequest) -> None:\n \"\"\"\n Fun\u00e7\u00e3o Timer Trigger que escreve 'Hello World' nos logs a cada 5 minutos.\n \"\"\"\n logging.info(\"Hello World! A fun\u00e7\u00e3o Timer Trigger foi executada.\")\n<\/code><\/pre>\n\n\n\n\nimport azure.functions as func\nimport logging\n\napp = func.FunctionApp()\n\n# Fun\u00e7\u00e3o Timer Trigger que executa a cada 5 minutos\n@app.timer_trigger(schedule=\"0 *\/5 * * * *\", arg_name=\"mytimer\")\ndef timer_main(mytimer: func.TimerRequest) -> None:\n logging.info(\"Hello World! Timer Trigger executada.\")\n\n# Fun\u00e7\u00e3o HTTP Trigger que responde a pedidos HTTP (GET\/POST)\n@app.route(route=\"hello\", methods=[\"GET\", \"POST\"])\ndef http_main(req: func.HttpRequest) -> func.HttpResponse:\n name = req.params.get(\"name\")\n if not name:\n try:\n body = req.get_json()\n if isinstance(body, dict):\n name = body.get(\"name\")\n except ValueError:\n name = None\n\n if name:\n return func.HttpResponse(f\"Ol\u00e1, {name}!\", status_code=200)\n\n return func.HttpResponse(\n \"Por favor, envia o par\u00e2metro 'name' na query ou no corpo.\",\n status_code=400,\n )<\/code><\/pre>\n\n\n\nBlueprint<\/h3>\n\n\n\n
\n
<project_root>\/\n\u2502\n\u251c\u2500\u2500 function_app.py # Regista os blueprints\n\u251c\u2500\u2500 http_blueprint.py # Blueprint com fun\u00e7\u00f5es HTTP\n\u251c\u2500\u2500 outro_blueprint.py # Outro m\u00f3dulo com fun\u00e7\u00f5es espec\u00edficas\n\u251c\u2500\u2500 host.json\n\u251c\u2500\u2500 local.settings.json\n\u251c\u2500\u2500 requirements.txt\n\u251c\u2500\u2500 .funcignore<\/code><\/pre>\n\n\n\n
<\/p>\n\n\n\nimport azure.functions as func\n\nbp = func.Blueprint()\n\n@bp.route(route=\"hello\")\ndef hello(req: func.HttpRequest) -> func.HttpResponse:\n user = req.params.get(\"user\")\n return func.HttpResponse(f\"Ol\u00e1, {user or 'mundo'}!\")\n<\/code><\/pre>\n\n\n\nimport azure.functions as func\nfrom http_blueprint import bp\n\napp = func.FunctionApp()\napp.register_functions(bp)\n\n<\/code><\/pre>\n\n\n\nO Equil\u00edbrio entre Azure Functions e Python: Vantagens e Desafios<\/h2>\n\n\n\n
![\"\"](\"https:\/\/b2f.pt\/wp-content\/uploads\/2026\/02\/blog_foto_proscons-1024x416.png\")
<\/figure>\n\n\n\nModelos de Pagamento<\/h2>\n\n\n\n